- Dillo-dev - lists.mailman3.com

RFC: removing the search dialog

by jcid＠dillo.org

Hi, Finally I got some time to answer this subject that needs some thought. > [Justus wrote:] > I was thinking about improving the dillo experience by adding some > functionality / shortcuts people have come to expect. But what people > expect is influenced by their background, their choice of desktop > environment and platform. Yes, the main point is different people like things in different ways. If we can provide a simple way to do things and offer the possibility to customize _some_ things, better. I believe one of the important things that we could support is custom keyboard shortcuts in dillorc. There are different shortcut sets, hardcoded into the user's brain, and they depend on what apps. the person is accustomed to use. For instance, if I've been using an editor where the "find text" function is F3, I'd like to have F3 do the same in dillo. > [Justus wrote:] > We could pick one / some user interface guideline(s) ([1] lists some) > and try to adhere to it / them. Or we could pick one popular browser and > copy its 'feel'. Dillo has come to have it's own "simple" feel, and users have been communicative in making clear they like it. Now that we changed the UI, we have to define some things though. The basic model behind dillo is simplicity achieved with: * right-click context menus. * providing some keyboard shortcuts. As stated before, we can improve it by allowing custom keybindings. On Sat, May 24, 2008 at 04:44:32AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey :) > > I hacked up opera (at least I _think_ they do it this way) style search > engine handling. I am not too happy with what I did to the config file > parser, but it works for now :). I like the idea of having multiple search engines. As a matter of fact since some years (But manpower/priorities etc...). Well, the CLI is mainly for advanced users, and I'd like to provide a UI that's orthogonal with what we have before tackling a CLI. For instance, the same search engines can be listed from a right-click menu on the search button. e.g. .------------------. . Google . . Wikipedia . . Free Dictionary . . Linux Packages . . SomeWhere Else . '------------------' Now, if a dialog pops-up: .-------------------------------------. . Search Wikipedia: . . [ ] . . [Cancel] [OK] . '-------------------------------------' it'd be quite simple and mnemonic. OTOH, if instead of dialog, the Location bar is focused, it'd not be clear for a new user whether it is for an URL or a new text string. The pop-up provides enough clues. If the pop-up dialog is to be avoided, it'd be nice to have it displaying the same information in the panel, perhaps hiding the navigation buttons. .----------------------------------------------------------------------. . Search Wikipedia: . . [ ] [P] . '----------------------------------------------------------------------' (now we have enough visual clues) Why up and not down like findtext, because that way is easier to tell web searching from page searching (I used to make that mistake a lot! :-) BTW, I don't yet know why avoiding pop-up dialogs is considered good. Don't get me wrong, I prefer the find text bar as it is now, but for other things, I don't yet see the problem. For instance on popup dialogs, messages and inputs. <topic change> Ctrl-X shortcuts in menus: This is another topic that needs feedback. The simplicity of current right-click menus is nice, but they don't provide mnemonic feedback on what shortcuts the listed items have. Probably having the shortcuts listed outclasses the readability, and they should be back, together with a shortcut customization scheme. > I am not sure what I would like to see, but for the moment I'd go with > dictionaries and the ability to include other files. This way we could > ship some config files (think browser personalities) and the user could > include the one he likes best and fine tune the settings in his personal > dillorc. AFAICS multiple dillorc files are simpler. > I was also unsure about the proper way to inform the user of errors and > I believe the reason for this is simply that there is no mechanism to do > this properly. Currently there are two ways: * pop-up dialog message. * status bar message. Openning a new dillo window with a custom HTML message is an option too. The advantages/disadvantages should be considered. For instance, with "view source", there's the clear advantage of having "find text" functionality for free. -- Cheers Jorge.-

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 06:04:07PM +0200, Johannes Hofmann wrote: > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > I've seen occasional segfaults in recent weeks, and > > > > twice now I've been able to catch them when I remembered > > > > to have gdb going (and, well, zero times when I remembered > > > > to have ulimit -c unlimited) > > > > > > I had some of these segfaults too. > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > #0 0x00000048 in ?? () > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > attrs=0x81dfc08) at layout.hh:253 > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > layout=0x815ca58) at style.cc:287 > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > layout=0x815ca58) at style.hh:587 > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > at style.hh:505 > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > widget=0x827b3b0) at layout.cc:175 > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > Data=0x821d324) at web.cc:94 > > [snip] > > > > My guess at the problem: > > > > StyleTable will give you back whatever Style matches your attrs, > > > > but maybe that Style was created with a different layout. > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > associated with a layout too. > > > > It looks like style uses layout to get to platform. I wonder whether > > it would go against any dw rules to let style have platform. > > > > My problem is that I don't understand why fontsTable and > colorsTable need to be platform specific in the first place. > As long as their members match they should be sharable - even > if they are used for different platforms. > > I would just make them static members of Font and Color > respectively. That way we would no longer need the layout parameter > in the *::create methods. To make clear what I mean, here comes the patch: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dw2 http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2 (they are too large for the list). I'm not sure why Sebastian avoided that possiblity. Maybe the virtual destructors which are needed in this implementation? Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this. Cheers, Johannes

June 7, 2008

should zlib be required?

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > On Sat, Jun 07, 2008 at 09:33:51PM +0200, Enrico Weigelt wrote: > > If Dillo requires zlib by itself, it should import it propery > > (eg. via pkg-config). > > ...and since when does zlib provide any pkg-config glue? The OSS-QM branch does for quite a long time, and uptream has signalled to include my patch. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

Future of dillo2

by weigelt＠metux.de

* Jorge Arellano Cid <jcid(a)dillo.org> schrieb: Hi, > i. - Increase the development team by adding 6+ new developers. > ii.- Getting more involved with other projects. you can add me, as long as no C++ stuff is involved. (don't like it's overhead). I'm already working on German translation. > * Planning for CSS, floating objects and TABS. > (this are important features to a nice browsing experience) Missing CSS is really bad. I'm planning to write an universal but small CSS parser (as an separate library). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

should zlib be required?

by joerg.sonnenberger＠web.de

On Sat, Jun 07, 2008 at 09:33:51PM +0200, Enrico Weigelt wrote: > If Dillo requires zlib by itself, it should import it propery > (eg. via pkg-config). ...and since when does zlib provide any pkg-config glue? Joerg

June 7, 2008

should zlib be required?

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > Should zlib be required? > > I notice that testing for zlib is currently just a part of > deciding whether to enable png. I either need to make configure.in > require it, or make zlib optional with some ifdefs. libpng's zlib-dependency is not Dillo's business. So you should fix configure.in to properly call pkg-config (this was the first thing I did in my branch) If Dillo requires zlib by itself, it should import it propery (eg. via pkg-config). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > Justus wrote: > > I hacked up opera (at least I _think_ they do it this way) style search > > engine handling. > > In my dream world, web browsers would have command lines instead of > location bars. That would be really cool. A few days ago I thought of something like that for Gimp: * all important objects are made accessible via 9P * an shell (eg. bash) is extended to support 9P directly * an special terminal (eg. via splitvt) runs both shell and some status like app * user commands can be easily written as shellscript functions cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Justus Winter <4winter(a)informatik.uni-hamburg.de> schrieb: Hi, > I hacked up opera (at least I _think_ they do it this way) style search > engine handling. I am not too happy with what I did to the config file > parser, but it works for now :). The parser is beautiful in its > simplicity, but it has its limitations (like not being able to handle > dictionaries). What exactly do you mean w/ "dictionaries" ? An list of values ? Then simply use an extra text file. I'm currently developing an tiny desktop environment for unexperienced users and there I often need hierachical config data (even w/ binary content). The filesystem (plus atoi()+friends) is completely enough for that purpose. Can't imagine anything simpler ;-P All filesystem access runs through my userland vfs library, libmvfs. So it's trivial to use other datasources than the local fs, eg. via 9P. > I am not sure what I would like to see, but for the moment I'd go with > dictionaries and the ability to include other files. Includes and macros can be easily done via cpp. > I was also unsure about the proper way to inform the user of errors and > I believe the reason for this is simply that there is no mechanism to do > this properly. > > I am thinking about using the browser widget to render error pages like > most of the mainstream browsers. Any thoughts on this one? Isn't an simple popup window enough ? <snip> > +# The syntax is > +# > +# search_url="<id>|<url>" > +# > +# This sets the search URL to use with "<id> <keywords>". > +# %s in the URL is replaced with keywords separated by '+'. > + > +search_url="g|http://www.google.com/search?q=%s" > +search_url="ly|http://search.lycos.com/default.asp?query=%s" > +search_url="aw|http://www.alltheweb.com/search?cat=web&query=%s" > +search_url="y|http://search.yahoo.com/search?p=%s" > +search_url="l|http://localhost/cgi-bin/htsearch?words=%s" > +search_url="cc|http://search.creativecommons.org/?q=%s" > +search_url="d|http://www.dict.cc/?s=%s" I'd prefer to have this in an extra file. Separation via whitespace seems to convenient to me. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

Executing commands via URL

by weigelt＠metux.de

Hi folks, I'd like to use Dillo for an help system and control center on an end-user desktop appliance. Therefore I need it to execute certain commands. But Dillo itself should not fork/exec itself, instead send the commands to some special daemon via an 9P channel. An simple approach could be coding an dpi which just parses the requested URL and sends the actual command to the exec server through 9P. But I have to make absolutely sure that commands can only be sent when coming from certain pages. How can I achieve this ? thx -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 04:34:04PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > > I've seen occasional segfaults in recent weeks, and > > > > > twice now I've been able to catch them when I remembered > > > > > to have gdb going (and, well, zero times when I remembered > > > > > to have ulimit -c unlimited) > > > > > > > > I had some of these segfaults too. > > > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > > > #0 0x00000048 in ?? () > > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > > attrs=0x81dfc08) at layout.hh:253 > > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > > layout=0x815ca58) at style.cc:287 > > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > > layout=0x815ca58) at style.hh:587 > > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > > at style.hh:505 > > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > > widget=0x827b3b0) at layout.cc:175 > > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > > Data=0x821d324) at web.cc:94 > > > [snip] > > > > > My guess at the problem: > > > > > StyleTable will give you back whatever Style matches your attrs, > > > > > but maybe that Style was created with a different layout. > > > > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > > associated with a layout too. > > > > > > It looks like style uses layout to get to platform. I wonder whether > > > it would go against any dw rules to let style have platform. > > > > > > > My problem is that I don't understand why fontsTable and > > colorsTable need to be platform specific in the first place. > > As long as their members match they should be sharable - even > > if they are used for different platforms. > > > > I would just make them static members of Font and Color > > respectively. That way we would no longer need the layout parameter > > in the *::create methods. > > > > What am I missing here? > > I may be wrong here, but I think the idea is that the colors or fonts > in the tables are currently FltkColor/FltkFont, but they could in principle > be mixed together with ones from another toolkit. Yes, I also read the comment in platform.hh about Style Resources. But still, if every implementation of Font or Color would handle its caching on its own with a static hash table, it should still work. If there should be a GtkFont class some day, it would have its own static hash table. I would rather see the need for a Font factory in platform that creates the right sort of Font for that platform. > > Hmm. I wonder whether it would break anything to change > a_UIcmd_browser_window_new() to have a single static FltkPlatform... Yeah, I thought about that too. I think apart from the current delete platform; in the Layout destructor that should work. And we could delete platfrom at the level where it was created. But all the platform stuff is difficult to understand as we currently only have one.

June 7, 2008