January 2011 - Dillo-dev - lists.mailman3.com

Copy and paste from page content area

by obeythepenguin＠gmail.com

On Fri, 07 Jan 2011 07:52:06 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hm, I would have thought that copy/paste just works on Windows > via the fltk::copy() call in FltkPlatform::copySelection(). > Does copy/paste work for fltk2/test programs on Windows? > > Cheers, > Johannes Copy/paste works from text boxes with the keyboard shortcuts. Select-and-middle-click works within FLTK (for example, I can copy from the content area to the address bar, no problem), but definitely not to other Windows apps. You'd think it would just work, but when you're dealing with a toolkit as badly broken as FLTK, just about anything is possible -- and don't get me started on X11-isms. I have not tried the test programs, but I will when I have a chance. Fortunately I'm no stranger to patching FLTK. Cheers, ~Benjamin

Jan. 7, 2011

hg repo

by corvid＠lavabit.com

Johannes wrote: > I would go with a separate repo for fltk-1.3 development. It's still > a branch, so we can use 3-way merging to keep things in sync with > mainline. The only difference is that you don't get fltk-1.3 > development stuff automatically when cloning the main repo - which I > think is a good thing. > Once it's ready we pull it over in the main repo. That's the same > procedure we used for the CSS-experimental branch. Andreas added a repository for me. I've done most of the really mindless parts now, so now we merely need to do all of the hard parts!

Jan. 7, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Jan 04, 2011 at 12:43:49PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Tue, Jan 04, 2011 at 08:48:05AM +0100, Diego . wrote: > > [...] > > Second. I want to suggest to not to remove the fltk 2.0 support code from dillo. > > > > DilloWidget support more than one "backend" so fltk 1.3 can be added > > whitout remove fltk 2.0 and selected at compile time or even runtime. > > Using 1.3 and compile time as sane defaults, of course. > > Unfortunately this is not true. Dw has an abstraction layer, > but all the user interface is native. I think it wouldn't even make sense to have an abstraction layer for the GUI. The GUI is concentrated in a small number of files in src/* and those files have to be ported. An abstraction layer here would complicate things more than it would help. > > > > A test version that draw 2 windows aech one with a "backend" can ve > > used to compare visual results during the port to 1.3. > > > > To support 2 "backend" now can heltp to support others in the future. > > ?what about a directfb one? Debian instaler will thanks it even i them > > use X now. > > Given the manpower, this *may* be possible. Although I don't > see much worth in supporting a dead library, given the new one is > less buggy and more capable. I would fully move over to fltk-1.3. We still keep the fltk2 code in the history. Of course if someone wants to maintain a fltk2 branch, that would be nice. Cheers, Johannes

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote: > Fredrik wrote: > > On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote: > > > * Can corvid make another repo in the same server? (e.g. for the port > > > to fltk-1.3) > > Isn't it better to just make an other branch in the same repo? Can't everybody > > with commit access do that? That should make bug fix sharing easier, > > right? > > How much does that complicate usage? Is it pretty much 1) name a new branch > and 2) use the same hg commands as usual but add some branch argument? I would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch. Cheers, Johannes

Jan. 7, 2011

Copy and paste from page content area

by Johannes.Hofmann＠gmx.de

On Wed, Dec 29, 2010 at 03:13:02PM -0500, Benjamin Johnson wrote: > On Wed, 29 Dec 2010 14:56:43 -0500, corvid <corvid(a)lavabit.com> wrote: > > >It has that mechanism where you highlight text with the left mouse button > >to select it and middle button to paste somewhere, but it doesn't do the > >one that uses control keys (which I've never understood the value of). > > Non-X11 systems don't have the select-and-middle-click mechanism, > and with most X11 toolkits (Qt, GTK+, etc.), the control key > mechanism is more persistent. > > Anyway, thanks for the answer. That's one of the next things I was > planning to implement. Hm, I would have thought that copy/paste just works on Windows via the fltk::copy() call in FltkPlatform::copySelection(). Does copy/paste work for fltk2/test programs on Windows? Cheers, Johannes

Jan. 7, 2011

[patch]: more spring cleaning of configure.in

by corvid＠lavabit.com

Jeremy wrote: > Time to retire some more obsolete autoconf macros. See [1] for > details. > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / AC_LANG_PROGRAM . > > This doesn't break for me, but it affects some host-dependent > parts of configure.in . It would be good to know that this works > on hosts with unusual socket / iconv library routines. > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL . > > This only affects target OSes *other* than linux, solaris, osf1 > and minix. Can anyone test on such a thing? > > 5: Indentation tweak for consistency. Works without giving me any problems...

Jan. 6, 2011

configure.in

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 05, 2011 at 09:46:29PM +0000, corvid wrote: > > In configure.in, why is it > > LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` > > if we use the system png/jpeg/etc. libraries and not > > the fltk ones? I just tried removing the --use-images > > argument, and everything still works for me. > > Probably because that way it worked with an older version. > Does the generated binary size change? Or is there a change > with ldd? No difference. (I was hoping it might make it a bit smaller.) > If the button icons load OK, and the file chooser works, there > should be no problems. Those widgets *may* need the internal > image handling (but I don't know for sure).

Jan. 6, 2011

configure.in

by jcid＠dillo.org

On Wed, Jan 05, 2011 at 09:46:29PM +0000, corvid wrote: > In configure.in, why is it > LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` > if we use the system png/jpeg/etc. libraries and not > the fltk ones? I just tried removing the --use-images > argument, and everything still works for me. Probably because that way it worked with an older version. Does the generated binary size change? Or is there a change with ldd? If the button icons load OK, and the file chooser works, there should be no problems. Those widgets *may* need the internal image handling (but I don't know for sure). -- Cheers Jorge.-

Jan. 6, 2011

[patch]: more spring cleaning of configure.in

by onepoint＠starurchin.org

Time to retire some more obsolete autoconf macros. See [1] for details. 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . 2: Replace AC_ERROR with AC_MSG_ERROR . 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / AC_LANG_PROGRAM . This doesn't break for me, but it affects some host-dependent parts of configure.in . It would be good to know that this works on hosts with unusual socket / iconv library routines. 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL . This only affects target OSes *other* than linux, solaris, osf1 and minix. Can anyone test on such a thing? 5: Indentation tweak for consistency. Regards, Jeremy Henty [1] http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#…

Jan. 5, 2011

configure.in

by corvid＠lavabit.com

In configure.in, why is it LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` if we use the system png/jpeg/etc. libraries and not the fltk ones? I just tried removing the --use-images argument, and everything still works for me.

Jan. 5, 2011