Yes or No: optional compilation of 'extra' features
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@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
On Thu, 25 Sep 2003 14:51:45 +0200 Frank de Lange <frank@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
* Frank de Lange <frank@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
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@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
On Thu, Sep 25, 2003 at 02:51:45PM +0200, Frank de Lange wrote:
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...
Judging by previous threads in this list, a number of people seem to strongly dislike tabs, so it would seem that DISABLE_TABS is a good thing. (I personally disable tabs, but only because I use a tabbing window manager. I think having tab support in Dillo is a great thing.) I'm guessing almost everybody wants to have frames, so maybe removing the conditional compilation of frames is worthwhile for the sake of simplifying code. Thanks for all your work, Frank. Frames support is really nice for browsing groups.google.com. Paul
On Thu, Sep 25, 2003 at 01:53:01PM -0400, Paul Pelzl wrote:
Thanks for all your work, Frank. Frames support is really nice for browsing groups.google.com.
:-) That was one of my main reasons to implement frames... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
I'm guessing almost everybody wants to have frames, so maybe removing the conditional compilation of frames is worthwhile for the sake of simplifying code.
Not only everybody *wants* it. Afterall, frames are part of the HTML standard. So it makes sense to have them. But then again, as far as I understood some of the last e-mails from Jorge : isn't he reviewing this patch now or pretty soon ?
Thanks for all your work, Frank.
I second that ! Great work ! Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
On Thu, Sep 25, 2003 at 09:17:12PM +0200, Andreas Schweitzer wrote:
I'm guessing almost everybody wants to have frames, so maybe removing the conditional compilation of frames is worthwhile for the sake of simplifying code.
Not only everybody *wants* it. Afterall, frames are part of the HTML standard. So it makes sense to have them.
But then again, as far as I understood some of the last e-mails from Jorge : isn't he reviewing this patch now or pretty soon ?
It was in reaction to comments from Sebastian that I posed this question to the list. He suggested removing the conditional compile, but I want to know what the list has to say on this. As a quick look at the list archives will show, not everyone likes these new additions to Dillo. I have already removed some preferences which could be combined (frame_blank_in_tab and tab_on_middle_click -> tab_instead_of_window) or which should be defaulted to the new functionality (document_title_use_url). Other suggestions Sebastian made are: - Remove tab title compression/shortening (I might create a new label widget which compresses/shortens text to a given size for this functionality) - exchange tab_load_in_background with a UI element/choice (I think this should be delayed until Dillo has a preference UI/plugin to avoid unnecessary complexity and one-off solutions) - rename "DilloDoc" to something else (I do not agree, DilloDoc is descriptive and short) The current state of the patch is: - still have conditional compile - have removed unnecessary preferences - have removed some recent changes to CVS nav.c which conflict with document/interface separation (have mailed Jorge about this) - have added incremental search and status-bar search widget (instead of popup) I will release a new version today or tomorrow Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
* Frank de Lange <frank@unternet.org> [09-25-03 16:14]:
On Thu, Sep 25, 2003 at 09:17:12PM +0200, Andreas Schweitzer wrote:
I'm guessing almost everybody wants to have frames, so maybe removing the conditional compilation of frames is worthwhile for the sake of simplifying code.
Not only everybody *wants* it. Afterall, frames are part of the HTML standard. So it makes sense to have them.
But then again, as far as I understood some of the last e-mails from Jorge : isn't he reviewing this patch now or pretty soon ?
It was in reaction to comments from Sebastian that I posed this question to the list. He suggested removing the conditional compile, but I want to know what the list has to say on this. As a quick look at the list archives will show, not everyone likes these new additions to Dillo.
The _tabbed_ browsing is wonderful and, afaiac, necessary, along with the tab_on_middle_click.
- exchange tab_load_in_background with a UI element/choice (I think this should be delayed until Dillo has a preference UI/plugin to avoid unnecessary complexity and one-off solutions)
acceptable
I will release a new version today or tomorrow
Looking forward. Will provide a SuSE 8.1 rpm if I am able to compile. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
On Thu, Sep 25, Frank de Lange wrote:
It was in reaction to comments from Sebastian that I posed this question to the list. He suggested removing the conditional compile, but I want to know what the list has to say on this. As a quick look at the list archives will show, not everyone likes these new additions to Dillo.
Its not a matter of liking or not, users may simply ignore tabs (and there may perhaps be a _user_ option for alternative presentations of frames). However, conditional compilation makes maintaining more difficult (and since that's the task of Jorge and me, the list is the wrong place to ask), so it is a question whether the reduced binary size outweighs the increased maintaining problems.
I have already removed some preferences which could be combined (frame_blank_in_tab and tab_on_middle_click -> tab_instead_of_window) or which should be defaulted to the new functionality (document_title_use_url). Other suggestions Sebastian made are:
- Remove tab title compression/shortening (I might create a new label widget which compresses/shortens text to a given size for this functionality) - exchange tab_load_in_background with a UI element/choice (I think this should be delayed until Dillo has a preference UI/plugin to avoid unnecessary complexity and one-off solutions)
What I meant is that the link menu should have to entries, "Open link in new tab", and "Open link in new background tab" (or so). Options should reflect different user's taste, while this difference depends on the situation.
- rename "DilloDoc" to something else (I do not agree, DilloDoc is descriptive and short)
In a local, experimental version of dillo, I've added a new module, representing the document in a DOM-like way, and which was this morning renamed from "doc.[ch]" to "doctree.[ch]". Your DilloDoc represents mainly the interface part of the document, there are other aspects. Sebastian
On Tue, Sep 30, 2003 at 04:41:19PM +0200, Sebastian Geerken wrote:
Its not a matter of liking or not, users may simply ignore tabs (and there may perhaps be a _user_ option for alternative presentations of frames). However, conditional compilation makes maintaining more difficult (and since that's the task of Jorge and me, the list is the wrong place to ask)
...beep... wrong I could of course split the tree, and maintain the tabbed/framed version separately. The list is the place to ask all developers, there is no hierarchy in this brave new world, if one does not pick up a task someone else will... I think the list is a good place to ask things like this, since that is the place where (prospective) developers go for information on these issues. , so it is a question whether the reduced binary
size outweighs the increased maintaining problems.
For you, maybe. For someone who wants as small a program as possible, maybe not. Who are we to say? The thing is, currently there is a clear separation in the code, which does seem to be beneficial for at least some people. Removing that separation makes it a bit easier to maintain the code later on, but also removes the benefits. Choice is good... The needs of the many, or the few, outweigh the needs of the one (thanks, Spock). Anyway, I vote to keep the separation of the tab code, but remove the separation for the frame code.
What I meant is that the link menu should have to entries, "Open link in new tab", and "Open link in new background tab" (or so). Options should reflect different user's taste, while this difference depends on the situation.
That can be implemented simply, but clutters the menu. I think having the option to chose a default behaviour is a good thing. The default is eg. used when opening a tab for the "_blank" URL target, on middle click, etc. Renaming Doc to something else is no big deal, but should only be done when really needed. And Doc does not deal with presentation, it deals with keeping state for a document. Presentation is BrowserWindow, Tab, Frameset, Frame. Or it should be, in any case. The separation is not really complete yet... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
On Thu, 25 Sep 2003 14:51:45 +0200 Frank de Lange <frank@unternet.org> wrote:
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.
25 KB can be important on PDAs. I guess having real frame support is not always a good idea on PDAs because of the low resoltion. On many pages you can easily find the navbar and then go to the content pages from there. So the simple frame support now in cvs is enough in some situations. Greetings Andreas Kemnade
participants (7)
-
Andreas Kemnade -
Andreas Schweitzer -
Frank de Lange -
Patrick Shanahan -
Paul Pelzl -
Sebastian Geerken -
Victor Sahlstedt