- Dillo-dev - lists.mailman3.com

recent changes to nav.c

by Frank de Lange

Jorge, Recently you added a new function (a_Nav_push_nw()) to nav.c. Though that function works fine, it should not be there... Why not? IMO, nav.c should NOT be concerned with windows, tabs, frames or whatever 'visual/physical' location a document is displayed in. It should just concern itself with the state of the document itself. This way, interface and document code are better separated, making it much easier and cleaner to add interface functionality (like tabs, frames, whatever) to Dillo. I have removed this function from my tab/frame patch, as the functionality it provides is - and has for a long time - already present in commands.c. That seems to be a better location for this type of functionality (even though commands.c does end up being a sort of grab-bag for miscellaneous stuff, maybe it should be reorganized a bit...) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Frank de Lange

On Thu, Sep 25, 2003 at 09:52:20AM -0500, Patrick Shanahan wrote: > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... > > #and ifndef DISABLE_FRAMES) and tell me whether the savings in space > > #are worth the > > added complexity... > > IANAP, but why not control the _optional_ FEATURES thru the rc file, > (on/off, yes/no, 1/0)? That is possible, but it does not save any space in the resulting binary. Conditional compilation does. This can be an issue, even though the total size of tabs+frames tops at about 25 K. If I remove the conditional compilation, I will probably add a pref to disable tabs though, as these seem to be 'controversial'... (as similar functionality can be provided by some WM's) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 25, 2003

errno and glibc

by Frank de Lange

Hi'all, Some of you might have run into the same problem as I did when I tried to compile the latest CVS with -Werror: dpi_service.o(.text+0x1d4): In function `dpi_dir': ../../../dillo_tabs/dpid/dpi_service.c:127: undefined reference to `errno' dpi_service.o(.text+0x3fc): In function `rd_dpi_dir': ../../../dillo_tabs/dpid/dpi_service.c:187: undefined reference to `errno' dpi_service.o(.text+0x57b):../../../dillo_tabs/dpid/dpi_service.c:211: undefined reference to `errno' dpi_service.o(.text+0x8df): In function `send_servers_list': ../../../dillo_tabs/dpid/dpi_service.c:290: undefined reference to `errno' This is caused by the failure to include <errno.h>, which is where errno is declared. Just add #include <errno.h> to dpid/dpi_service.c and it compiles cleanly (at least here...) <PATCH> --- dillo/dpid/dpi_service.c 2003-09-15 02:56:41.000000000 +0200 +++ dillo_tabs/dpid/dpi_service.c 2003-09-25 17:13:31.263098504 +0200 @@ -25,6 +25,7 @@ #include <string.h> #include <dirent.h> #include <error.h> +#include <errno.h> #include <glib.h> #ifdef TEST #include "testdat.h" </PATCH> Jorge, can you apply this patch? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [09-25-03 08:39]: > > Those of you who have tried my tab/frames patch will know that I > usually make all 'extra' features optional. This allows those who {do > not {need|like}|can not afford} those features to leave them out of > the resulting binary. However, it also makes the code somewhat more > complex, as the optional features are enabled/disabled through > conditional compilation (#ifdef/#ifndef....#endif). The space saved > by leaving out tabs and frames is currently about 25 kilobytes (Kib, > kB, KB, choose your acronym...). > > I have gotten some comments on this, suggesting the removal of these > conditional statements. This way, Dillo would ALWAYS have the extra > features (tabs and frames). > > Before I say 'yes' or 'no' to these suggestions, I'd like to know > what your thoughts are on this. > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... > #and ifndef DISABLE_FRAMES) and tell me whether the savings in space > #are worth the > added complexity... IANAP, but why not control the _optional_ FEATURES thru the rc file, (on/off, yes/no, 1/0)? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Victor Sahlstedt

On Thu, 25 Sep 2003 14:51:45 +0200 Frank de Lange <frank(a)unternet.org> wrote: > I have gotten some comments on this, suggesting the removal of these > conditional statements. This way, Dillo would ALWAYS have the extra features > (tabs and frames). Well, I doubt 25kB is an issue for anyone and if people are uncomfortable with tabs they still have the ability to open a new window. I can't speak for the majority but personally I don't see a reason why anyone wouldn't want the frames. > Before I say 'yes' or 'no' to these suggestions, I'd like to know what your > thoughts are on this. > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... and > #ifndef DISABLE_FRAMES) and tell me whether the savings in space are worth the > added complexity... Personally, I don't think it's worth it. As I use the features myself though I might be a bit biased. - Victor

Sept. 25, 2003

Yes or No: optional compilation of 'extra' features

by Frank de Lange

Hi'all, Those of you who have tried my tab/frames patch will know that I usually make all 'extra' features optional. This allows those who {do not {need|like}|can not afford} those features to leave them out of the resulting binary. However, it also makes the code somewhat more complex, as the optional features are enabled/disabled through conditional compilation (#ifdef/#ifndef....#endif). The space saved by leaving out tabs and frames is currently about 25 kilobytes (Kib, kB, KB, choose your acronym...). I have gotten some comments on this, suggesting the removal of these conditional statements. This way, Dillo would ALWAYS have the extra features (tabs and frames). Before I say 'yes' or 'no' to these suggestions, I'd like to know what your thoughts are on this. So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... and #ifndef DISABLE_FRAMES) and tell me whether the savings in space are worth the added complexity... BTW, I do not mind either way... As always, look for the patch at http://www.geocities.com/ikbenfrank A new patch, with some new functionality (sorry Sebastian, functionality was added before you asked me not to add anything new...) will be ready soon. It improves upon the way frame margins are handled, adds an alternative for the find and load popup menu, and includes 'find as you type' (or 'incremental search'). Small parts of the patch (image menu, hand cursor, fixes to widgets) are slowly been added to CVS now. If you want to see the rest added as well, help me out and provide some feedback... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 25, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by Andreas Schweitzer

> I did follow the posts. As in any escalations, things took turns a > bit at a time. And I think not all burden is to be put onto Robin. > > I re-read the thread. I'm not out to find culprits, I hate this kind > of game. I agree. We should just leave this topic behind, it's not worth digging in the past. I think there were wrong words, wrong interpretations, taking issues too personally and whatnot. Actually, I've seen it a few times in totally different projects. And it just hurts the project. If people would talk to each other face to face, the parties would see more than just some (possibly) badly formulated words. > But I do believe that the list could have been more > cooperative. If they ask questions here, let's just answer them. For the sake of good software. Just my opinion. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 25, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by tomas＠fabula.de

On Wed, Sep 24, 2003 at 09:23:05AM -0700, Kelson Vibber wrote: > At 02:27 AM 9/24/2003, tomas(a)fabula.de wrote: > >I was quite sad to see the hostility you found on this list, and > >still don't understand why a windows port doesn't seem to be welcome. > > Go back and read the archives. In order. Just about all the feedback he > got was positive until he started complaining about how unwelcome he was. > > First thread: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-August/001036.html Some private mail has been written in between here. It's difficult to asess its importance. > Second thread: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001076.ht… > A few scattered messages: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/thread.ht… > > Seriously, follow the entire thread. I don't see how *any* of that can be > considered hostile before Mr. Rowe basically stated "Jorge doesn't want to > help me port to Windows, therefore you all hate me." I did follow the posts. As in any escalations, things took turns a bit at a time. And I think not all burden is to be put onto Robin. I re-read the thread. I'm not out to find culprits, I hate this kind of game. But I do believe that the list could have been more cooperative. Thanks -- tomas

Sept. 25, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by Kelson Vibber

At 02:27 AM 9/24/2003, tomas(a)fabula.de wrote: >I was quite sad to see the hostility you found on this list, and >still don't understand why a windows port doesn't seem to be welcome. Go back and read the archives. In order. Just about all the feedback he got was positive until he started complaining about how unwelcome he was. First thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-August/001036.html Second thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001076.ht… A few scattered messages: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/thread.ht… Seriously, follow the entire thread. I don't see how *any* of that can be considered hostile before Mr. Rowe basically stated "Jorge doesn't want to help me port to Windows, therefore you all hate me." Don't just take the "hostility" claim at face value, read for yourself and make up your own mind. (For the record, I see porting Dillo to Windows as a good thing, but I would much rather have seen a more friendly relationship between the core Dillo project and the Windows port. And from what I can see, Mr. Rowe brought any hostility on himself.) Kelson Vibber www.hyperborea.org

Sept. 24, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by tomas＠fabula.de

On Mon, Sep 22, 2003 at 04:16:32PM -0700, Robin Rowe wrote: > FYI, a screenshot of dillo running native on Mac OS X Aqua. > > http://heml.sourceforge.net/pix/dillo.aqua.811x734.png > > That and my Windows port are still under development. Looking to have those > ready for users by the end of the year. Thank you, Robin for your work. Although not a Windows user myself (alas, I'm nearly a strict free software user!), I do appreciate what you are doing, since it builds a bridge which might help people to meet free software. I was quite sad to see the hostility you found on this list, and still don't understand why a windows port doesn't seem to be welcome. (Folks, don't get me wrong: I don't want to start a flame war, we had it already. I would put strict criteria on whatever ports, mainly that they don't uglify the code all over the place. But heck, even Emacs has a Windows port, and that is a Damn Good Thing, IMHO). Regards -- tomas

Sept. 24, 2003