-----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 :). The parser is beautiful in its simplicity, but it has its limitations (like not being able to handle dictionaries). 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. 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? Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIN4EQoPmwNWhsaZYRAn93AJ9cVSrlojFB7rcRfDuuysS+iF9MrwCfY5rB Be/P/5ORephsPhmdBcyk+MM= =1rOv -----END PGP SIGNATURE-----
* corvid <corvid@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/ ---------------------------------------------------------------------
* Justus Winter <4winter@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/ ---------------------------------------------------------------------
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.-
* Jorge Arellano Cid <jcid@dillo.org> schrieb: Hi,
I believe one of the important things that we could support is custom keyboard shortcuts in dillorc.
ACK. Maybe would should go the way Mutt does: it internally works with commands, and keystrokes are mapped to commands. Such an simple command interpreter would be cool. If Dillo also provides an 9P server which publishes internal states and an command channel, it would be even cooler :)
* right-click context menus. * providing some keyboard shortcuts.
Both should be configurable.
AFAICS multiple dillorc files are simpler.
ACK 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/ ---------------------------------------------------------------------
Hi all, On Sun, 08 Jun 2008, Enrico Weigelt wrote:
* Jorge Arellano Cid <jcid@dillo.org> schrieb:
I believe one of the important things that we could support is custom keyboard shortcuts in dillorc.
ACK. Maybe would should go the way Mutt does: it internally works with commands, and keystrokes are mapped to commands.
Such an simple command interpreter would be cool. If Dillo also provides an 9P server which publishes internal states and an command channel, it would be even cooler :)
* right-click context menus. * providing some keyboard shortcuts.
Both should be configurable.
AFAICS multiple dillorc files are simpler.
ACK
I like the idea of having dillo CLI operational. May I suggest having a look at vimperator? It's (in my eyes) beautiful ;) Greetings Daniel
* Daniel Lord <elektro_news@gmx.de> schrieb: Hi,
I like the idea of having dillo CLI operational. May I suggest having a look at vimperator? It's (in my eyes) beautiful ;)
yep, would be cool. But that I could use in my current project (I'm building an DE for unexperienced users). I'd prefer a more generic approach: making everything available via 9P and let separate programs work on that filesystem. This also allows lot's other funny things, eg. an HTML external editor which directly operates on an document within an dillo vierwer ;-) 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/ ---------------------------------------------------------------------
participants (5)
-
4winter@informatik.uni-hamburg.de
-
corvid@lavabit.com
-
elektro_news@gmx.de
-
jcid@dillo.org
-
weigelt@metux.de