Patch update: Bug 220 - saving entered datas in forms
Hi, All ! There is an updated patch (against CVS) to save input values in memory when form is posted. http://tkk.ru/~eliterr/dillo/saving_values.diff WBR, Nikita
On Thu, 17 Apr 2003, Nikita V. Borodikhin wrote:
Hi, All !
There is an updated patch (against CVS) to save input values in memory when form is posted.
Thanks Nikita, both for the patch and for making it a link. I know it needs another revision and the only reason I haven't done it, is because I have a lot of things to sort in the project at this time. The Dillo project is slowly entering into what can be stated as a second stage in its development cycle. We're a single step away from https, Downloads and FTP. The funding initiative also has taken a lot of my time, but its yields is what has made my continued work possible. Now I have to plan for the future: after 0.7.2 is released (with Copy&Paste), most probably the pressure for adding new features will increase (it already had internally!). People will start thinking of using sourceforge an other sites with dillo, and I want the impression that lingers from using the browser there, is of a fast, stable and reliable tool. We're not far from there, and I owe a more detailed planning email to dillo-dev. For now, I'm on 0.7.2 release, then I'll focus on the SSL plugin (asking for the cooperation of all of those that had showed interest and code to make https work). I already have a guy working on the downloads plugin (as his thesis), and as I made the FTP plugin, I know exactly how to integrate it with downloads. Appart from that, I still have to finish the design of dpi initialization, addition, managing etc. (needed to support several dpis at the same time). Add generic patch-reviewing/correcting/integrating, answering the mailing list, keeping the web site updated and you'll have an idea of my duties. Ah, we even hold some nice patches for Linear History, Image menu popup, cache size, speedups and so on, just because we haven't got them stable or polished enough to integrate (within the limited time of our prioritized schedules). Finally I want to send a big thank and my sincere recognition to all of you who have kept following and cooperating (patches, testing, informed comments, documentation, icons, etc) with this project for all (or scattered periods) of its lifespan. Without you, it wouldn't have become what it is today. Sincerely Jorge.-
On Thu, 17 Apr 2003 10:58:13 -0400 (CLT), Jorge Arellano Cid <jcid@softhome.net> wrote:
Finally I want to send a big thank and my sincere recognition to all of you who have kept following and cooperating (patches,
as a user i want to thank you and all others involved with dillo, its a great browser, big help for all of us and a proof that web browsing can be fast and fun again Muito obrigado higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
Hi, Just a comment on one of your plans :
Appart from that, I still have to finish the design of dpi initialization, addition, managing etc. (needed to support several dpis at the same time).
I think this will be important, since it kept me somewhat from playing with dpi's. I did some experiments, but an automatic dpi initilization makes coding much easier. And I have the feeling others think the same :-) Something like dpi:/foo/ starts the dpi foo[possible-extra-name-part] from some location like $PATH or some other "repository". And dpi:/foo/command passes "command" to the dpi foo. Just some rambling :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
I agree, I have been trying to 'break out' the bookmark dpi into a loadable object file, ( loads at runtime, and installs the button and such ), in order to do work on a dpi plugin myself. If something about loading dpi modules were in place it would be much nicer. I have tried to hack a list of dpi modules in .dillo/dpis which is loaded at runtime, but so far not much sucess. Is there a plan on how these things will work in the future ? Because then one can progress with the dpi itself and the infrastructure. / Lars Segerlund. Andreas Schweitzer wrote:
Hi,
Just a comment on one of your plans :
Appart from that, I still have to finish the design of dpi initialization, addition, managing etc. (needed to support several dpis at the same time).
I think this will be important, since it kept me somewhat from playing with dpi's. I did some experiments, but an automatic dpi initilization makes coding much easier. And I have the feeling others think the same :-)
Something like dpi:/foo/ starts the dpi foo[possible-extra-name-part] from some location like $PATH or some other "repository". And dpi:/foo/command passes "command" to the dpi foo. Just some rambling :-)
Cheers, Andreas
participants (5)
-
Andreas Schweitzer -
higuita -
Jorge Arellano Cid -
Lars Segerlund -
Nikita V. Borodikhin