- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] silent dillo? revised

by Andreas Schweitzer

On Mon, Aug 11, 2003 at 05:47:49PM -0500, Jorge A Ahumada wrote: > I love dillo and use it as my default browser when using help pages in > R. However, every time I invoke the help in R, dillo returns several > messages clogging my R prompt...Is there any way to run dillo in > 'silent' mode? You can lower the debug level. Search for DEBUG_LEVEL in the source and remove all occurences. That should remove a number of messages. If you know your way around you can try http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/ and look at the various patches. Most of them silence dillo, but some serve different purposes. Also, they are against 0.7.2 (at least right now), so double check. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 12, 2003

silent dillo? revised

by Jorge A Ahumada

I love dillo and use it as my default browser when using help pages in R. However, every time I invoke the help in R, dillo returns several messages clogging my R prompt...Is there any way to run dillo in 'silent' mode? thx, Jorge

Aug. 12, 2003

can dillo be silent?

by Jorge A Ahumada

I love dillo and use it as my default browser when using help pages in R. However, everything I invoke the help dillo returns several messages clogging my R prompt...Is there any way to run dillo in 'silent' mode? thx, Jorge

Aug. 12, 2003

Re: [Dillo-dev] focus on start

by mattias/spikboll

On Sun, 10 Aug 2003 10:21:30 -0400 Todd Slater <dontodd(a)columbus.rr.com> wrote: > When I launch Dillo, the content part of the window is not focused so I > have to click on the content to focus it and then I can page through it > using the keyboard. Is that intentional, and is there a way I can make > it start with the content part focused so I can immediately start > scrolling through a page? No need to click. Just press Tab, and you're set to go. /Mattias -- mattias östergren | /"\ compsci student | \ / ASCII Ribbon Campaign gävle, sweden | X No HTML in e-mail http://spikboll.net | / \

Aug. 10, 2003

focus on start

by Todd Slater

When I launch Dillo, the content part of the window is not focused so I have to click on the content to focus it and then I can page through it using the keyboard. Is that intentional, and is there a way I can make it start with the content part focused so I can immediately start scrolling through a page? Thanks, Todd

Aug. 10, 2003

Re: Re: [Dillo-dev] [patch] Remote Control

by Melvin Hadasht

Hi Tomas, You wrote: > Here are some comments for discussion. Take them with a grain > of salt: > > - I'd prefer case sensitivity (the unixy environment is case > sensitive, URIs are -- at least in part :-/ > You know, principle of least surprise and that. At first, I planned to implement mozilla-like options (which are documented as OpenURL but they are case insensitive: openurl works, too). Unix people are used to case sensitiveness, so I could switch to that, especially that there is no port to MSWindows or other case insensitive platform, yet (I have a doubt concerning VMS, though). > - Implementation. Why not implement this as a wrapper which > talks to the dpid? It would start Dillo if not already running. > > The advantages I see are: > > - the wrapper could clean up any mess Dillo might leave behind > on a crash. This is one of the open issues you mention. > (OK, Dillo doesn't crash, does it? but a simple wrapper > is less complex and thus less likely to crash). nedit comes with a small "nc" nedit-client that does something similar: if no server exist, it forks one. So you can live with just the "nc" command. I'll read more about the dpi stuff and will think about how it could be used. Thanks for your comments! -- Melvin Hadasht

Aug. 10, 2003

Re: [Dillo-dev] [patch] Remote Control

by tomas＠fabula.de

On Sun, Aug 10, 2003 at 12:39:48AM +0200, Melvin Hadasht wrote: > Hi, > > I just made a patch to add remote control for Dillo. > Terrific! Here are some comments for discussion. Take them with a grain of salt: - I'd prefer case sensitivity (the unixy environment is case sensitive, URIs are -- at least in part :-/ You know, principle of least surprise and that. - Implementation. Why not implement this as a wrapper which talks to the dpid? It would start Dillo if not already running. The advantages I see are: - the wrapper could clean up any mess Dillo might leave behind on a crash. This is one of the open issues you mention. (OK, Dillo doesn't crash, does it? but a simple wrapper is less complex and thus less likely to crash). - You could re-use the existing communication mechanism for dpi1, I think (I haven't looked deeply into this yet, though). The main disadvantage would be, of course, that you have to start dillo-wrapper instead of dillo, but may be we can convince folks in the list that this ie a Good Thing anyway (it would solve elegantly the `single dpid instance' issue, since it could look whether dpid is running before starting dillo). What do people think? Regards -- tomas

Aug. 10, 2003

[patch] Remote Control

by Melvin Hadasht

Hi, I just made a patch to add remote control for Dillo. 1. Summary: 1.1 Why? To be able to command Dillo from another process. E.g.: if Dillo is used as a help doc browser of a program, the program can implement context sensitive help and associate to each widget a help URL. The same Dillo instance can then be used to show the differents help docs. Other example, which also was the motivation of this patch: Sylpheed-Claws uses Dillo to render HTML mail, but currently it has to run a new instance each time the user views an HTML mail. Having only one instance is more efficient and improve responsiveness. 1.2. HowTo To be remote controlled, a Dillo instance must be explicitly started with a special command line option (-s, --server NAME), e.g.: dillo -s server A client instance sends commands to this server by referencing it and by using the -c, --command options, e.g.: a. dillo -s server -c "open(http://www.google.com)" -c "new-window(www.av.com)" b. dillo -s server http://www.google.com amounts to: dillo -s server -c "new-window(http://www.google.com)" Hence, running dillo -s server -c "open(URL)" mutliple times will launch only one instance of dillo at the first time, and the subsequent calls will just hand the arguments to the server. This is more practical than Mozilla's current behaviour where the user has to use two different commands to start and to control a server. The list of currently known commands is provided by the -H, --help-commands option: dillo -H Commands that can be used with the -c, --command option: open(URL) Open URL in current window. new-window(URL) Open URL in a new window. Exit() Terminate browsing session and exit. Command names are case insensitive. It is allowed to have more than one command option. New commands can be added, the syntax being: command(.*) 2. Ressources In dillorc: server_socket_path by default, it is "/tmp". It is used to create the socket name which is: $server_socket_path/dillo-$USER-$NAME. where $NAME is the server name from the -s, --server NAME option. E.g.: /tmp/dillo-john-help 3. Caveat If gtk specific command lines arguments are given, arguments are messed around, due to the fact that the patch delays gtk_init() after private arguments parsing, This will be fixed in the next version If a Dillo server does not quit cleanly, the socket corresponding to the server is not removed. Subsequent attempts to run a server with the same name will fail until the socket is removed (by default: /tmp/dillo-$USER-$SERVER_NAME). A solution is currently searched. The -c "exit()" works only when used from the client side The -c commands are currently ignored if no -s option is given. Any comments are welcome. Especially use cases for the remote control. 4. Details 4.1. Becoming a server Communication between server and client is done via UNIX domain socket. The advantage between this and FIFO being that a separate connection is made for each client, so communcation are guaranteed to not mixup. FIFO, on the other hand, can mixup communication of multiple clients if the messages are larger than some value (PIPE_BUF). This patch uses dynamic allocation for the messages received by the server. When the -s, --server NAME option is given, dillo checks wether a socket correspondig to that name is available and responding. If yes, it will hand any -c, --command CMD and any URL|FILE it finds in its command line options to that running server. URL|FILE are interpreted as "-c new-window(URL|FILE)". If no server socket is responding, it turns it self into a server by creating that socket. After that, it handles the -c, --command CMD and the URL|FILE options itself. 4.2. GUI initialisation The gtk_init() function is now called after dillo options parsing to speed up client execution. Indeed, a client instance does not need to initialise the GUI. This introduces the problem of messed up args if gtk args are given. This could affect the URL|FILE arguments. A solution would be to save them in a separate list for later processing. Another solution would be to interprete the URL|FILE arguments as -c open(URL|FILE) at an early stage. This will also help fixing the problem of the -c commands being ignored if no -s option is given. 4.3. Commands Commands are simple of the form: command(arg..). Arguments are parsed by the shell, so the user must take care that the command is interpreted as a single argument by the shell. Arguments should not contain unescaped parenthesis or spaces. Therefore, the following example is incorrect: dillo -s server -c open(file:///home/user/My documents) because: 1. the shell interprets the parenthesis, and 2. there is a space in the argument. This should be escaped in the following manner by using quotes: dillo -s server -c "open(file:///home/user/My documents)" It is easy to add new commands. -- Melvin Hadasht

Aug. 10, 2003

Re: [Dillo-dev] Question about frames (have them working, but...)

by Sebastian Geerken

On Tue, Aug 05, Frank de Lange wrote: > What does not work yet: > > - obeying frameset proportions. Currently all frames are allocated a default > size. I have the appropriate sizes for the frames at hand, but GTK does not > provide a means to size multiple widgets in a container relative to the > size of that container. The 'gtk_widget_set_usize()' (or GTK2's > gtk_widget_set_size_request() replacement function) are not suitable for > this purpose, although they can be used to set a minimum or absolute size > for rows/columns which have been specified that way (frameset rows=100,100,* > is easy, frameset rows=100,20%,3*,* is not...). > - the full_screen_off_button is not shown in frame documents. Use double-click > instead to toggle the full screen setting... > > These problems can be solved by creating a new widget for the frameset, but > that might be overkill. DwTable provides some of the needed features, but is is > overcomplicated for the task at hand (no colspan or rowspan in framesets, etc) > and lacks direct control over the height of table cells. If anyone has any > bright ideas on how to assign widgets sizes which are relative to their > container, speak up... Or, if anyone has already created (or at least thought > about creating) a 'frameset' widget, please let me know. No need to re-invent > the wheel... > > If I get no response, I will probably create a new widget based on GtkTable, > with some built-in sizing magic. I chose GtkTable over DwTable because the > former seems to be more suitable for the purpose than the latter. I might be > wrong, please tell me... I would not call this an overkill. Creating a new widget with a rather limited functionality (since only used for framesets) is not a big deal, at least for someone who is a bit expierienced in it, but in most cases better that working around limitations of other widgets. Furthermore, it gives us more control over extensions becoming necessary in the future. > - the full_screen_off_button is not shown in frame documents. Use double-click > instead to toggle the full screen setting... You may put the "Show Controls" button into the new widget, look at GtkScrolledWindow for inspiration. Sebastian

Aug. 9, 2003

Re: [Dillo-dev] Refresh tag patch...

by Tom Lisjac

On Fri, 2003-08-08 at 09:16, Jorge Arellano Cid wrote: > > For catalog searches, the librarians, teachers and kids love Dillo and > > prefer it to Mozilla on Linux or IE on Win98. > > This is very significative and encouraging: different kinds of > users, with varying degrees of expertise had a choice in your > lab, and they preferred Dillo! Yes! I think it's also worth mentioning that Dillo's performance and small footprint made it possible to build these workstations from older equipment that the school was preparing to throw away! Many more Linux boxes have been made available to the kids as a result! :) > > The *only* problem is that the > > card catalog server (Accent) uses sessions that require periodic client > > refresh. > AFAICS It'd be rare for a server to send a meta-refresh tags > because it can generate the page itself. Although I also see that > if the resource is elsewhere it can try to redirect the browser, > but again HTTP does it better. The server embeds a meta-refresh tag to re-home the lookup station after a search. Typically, students will do their card catalog queries, get the results and then walk away from the terminal. The refresh tag works well here because it will automatically reset the station back to the main search page for the next user. The librarians said that doing these resets manually was a source of distraction for them last Spring. > In anycase, please explain me in more detail what the desired > functionality is, to study how to make it happen for you. > > If it is a cache issue, Madis Janson has a patch for that (only > half reviewed by me, but with a good chance to make it into the > official tree). I hope this to be the case. Madis and a number of others were kind enough to point me at the patch. It provides meta-refresh along with a number of other nice features. One of the goals for this application, however, is to minimized the screen complexity and number of buttons that the bright and curious 8 years olds can push... so I'm trying to extract the meta-refresh code from the patch and apply it separately. Since C is not my first language, this is proving to be something of a challenge! :) Thanks and best regards, -Tom Lisjac http://theseus.sourceforge.net

Aug. 9, 2003