Re: [Patch] Added Local history button in GTK interface
by edi
Ok, third shot at it and hopefully the last one (sorry Daniel for
previous message, it contained makefile diff in patch).
General description:
This patch adds history button between forward and back in GTK
interface. This time for newly opened window AND tab (Ctrl-T
accelerator) focus stays on the URLbar. I've also formatted code
according to guidelines provided by Daniel and John.
To-do:
Next step would be to make this new button behave like it's older
brother in Firefox (on "clicked" event application will draw text list
of local history). And I'll check how to make local history window
transient (after duration, on focus lose?).
And I've been thinking - maybe it's a good idea to open local history
window as a new tab (like Speed Dial in Opera or it's equivalent in
Firefox) when it's invoked with accelerator or menu item.
--
Regards,
Chris Tarnowski.
-------------------------------
PGP Key-Id: C33C A45D
IRC: 3d1
14 years, 8 months
[patch] gtk toolbar buttons / theme
by Mark
Hi,
One of the improvements listed, is that the gui should adjust to match
GTK interface preferences
so far so good, the toolbar preferences should be working decently now;
I'll need to add logic to cope with netsurf's preferences being
different to GTK's when you open a new window, it seems the main trouble
for now is that there's no loading of the options table in the code;
after trying to code the menu images, I discovered that it is
automatically managed in GTK, there is an override possible to
allow/deny hiding images, though that would be a bit pointless
There may be a GTK bug when you open more than one window, close
one/some, then try to close the preferences window after altering the
preferences in the window that was kept open. It's sporadic though
rather than adding a new tab to the preferences window, I've changed
'font' to 'style' then put the combo there
Best
Mark
http://www.halloit.com
Key ID 046B65CF
14 years, 8 months
[Fwd: Regarding the Review of the project proposal on page reader]
by John-Mark Bell
-------- Forwarded Message --------
> From: Vishal <balaji(a)iitk.ac.in>
> To: John-Mark Bell <jmb(a)netsurf-browser.org>
> Subject: Regarding the Review of the project proposal on page reader
> Date: Tue, 31 Mar 2009 23:59:43 +0530
>
> Hi,
>
> I have submitted a project proposal for page reader section of
> Netsurf . You have gone through it already .And you have given some
> remark on that proposal . So I am mailing you this in that context.
> I don't know the normal protocol , but I will change my proposal
> according to your suggestions and I am mailing you , the changes I am
> doing in it to let you know my modifications.
> First thing , was concrete milestones or the basic idea to
> implement the page reader .
> Browser is a tool to open the raw data sent by the servers hosting the
> urls , which we try to open . Netsurf supports HTML 4.0 and CSS 2.1 ,
> that means data can have coded using HTML and CSS . Netsurf tries to
> interpret this code and lays out the interface in human
> readable/understandable form . So I will have to work on the way how
> Netsurf is interpreting HTML coding .I have to pass the required data to
> espeak , which is interpreted by the Netsurf from the raw code i.e. How
> Netsurf has decided what is the heading , which are the special links
> and tags and what is the cursor is pointing at. It is all there in the
> Netsurf coding , I will have to augment it so that this information is
> passed on to some other processing body , which happens to be espeak in
> our case.
> Then I will have to work on designing a front end for espeak to access
> and process the data passed on to it to work simultaneously with netsurf .
> This project has three parts :
> 1) understanding the Netsurf build up
> 2) augmenting or modifying the code to pass on some data to
> another body.
> 3) Making espeak to actually process this data .
>
> I have already worked in C in some of my course projects like :
>
> 1) I am designing a compiler(with limited features) for pascal
> using C programming language.
> 2) I have worked on Nachos (a small working OS model ), to
> implement additional features in it , like page tables , synchronization
> etc. Nachos is built using C++ , It needed a lot of core programming and
> data structure building . Though it was not purely C , but I think it
> was very similar experience .
>
> I am attaching some of my project work on pascal compiler and
> its not complete till now but It will be complete in next 1 and a half
> week . If you want to run it , just hit make in the folder.
> Parser.y contains the actual grammar and core work for the compiler.
> I am not sending nachos , because its a lot of files , only some of
> which I have edited.
>
> If you want to know , whether I am able to understand the Netsurf
> source code , I want to say that I have built the netsurf from its
> source code and I am analyzing the code , so that I will be able to
> understand how actually Netsurf is able to interpret the data.
> Actually the code I am sending to you is under construction , so it may
> look very messy , I am sorry for that . If you want any other evidence
> or you want to throw any challenge problem , I will be more than happy
> to accept it.
> Right now, I am observing , you people are busy fixing some of
> the GTK bugs , earlier being carried out by Netsurf . I was busy until
> now, I will try to further understand the layout engine of the Netsurf ,
> and see if I am of any help.
>
> Regards ,
> Vishal B Annapurve
> CSE
> Third year Under Graduate
> Indian Institute of Technology ,
> Kanpur
>
> P.S .
>
> Your notification/review on my project proposal was :
>
> Thank you for your application.
>
> We would like to see more detail about how you intend to implement the
> page reader, along with more concrete milestones.
>
> Additionally, we would like to see some evidence of your ability to write C.
>
14 years, 8 months
GSoC frames idea
by Paweł Blokus
Hello
As I would like to propose for the Core UI idea together with the frames stuff
I would like to discuss the best approach to handling frames. This is just
a starting draft and absolutely no details are described because I may not fully
understand the frames logic so the first thing I need to know is if that's the
right way to follow in order to develop it further.
Having this said - please read and comment, any feedback will be appreciated :).
For those whom I haven't bugged on #netsurf yet and who might prefer to discuss
there :) - my IRC nick is PaulB_.
The problem (thanks to kyllikki)
Currently the frames are treated as seperate windows in the OS. This forces the
core to take some assumptions on their behaviour which obviously can't be
the same across all platforms. For this reason only the RISC OS front-end
supports frames at the moment. This approach is not only unportable but also
overcomplicated.
The solution
What I would like to do is to split the functionallity the browser window has
currently into two parts - the browser window's and the frame's( drawing area's)
one.
The browser window would be responsible for everything which wouldn't be done
by the OS any more. This includes keeping track of which frame has
focus, sending
the events to the appropriate one, opening pages in the corret target etc.
The frames would have to handle scrolling logic( together with requesting
for the scroll bars), redrawing, dealing with mouse clicks and other events.
Also, it would be the frame then which would have to deal with the content.
In the matter of how the frame would be used to draw on a part of a screen I see
two basic approaches:
1. The whole page could be plotted into a single drawable surface( like it is
done at present when there are no frames), so basically it means keeping the
gui_window in the browser_window structure. A frame with its coordinates and
dimensions would represent a rectangle on that page thus making a frame-plot
a regular plot with the frame offsets added.
2. A frame would keep a reference to front-end specific data representing
the page rectangle. A set of gadgets would be nested in the window so that
they wouldn't need separate windows. This would let the scrolls and resizing be
done without additional coding. However, I am not sure if this would be possible
on every platform( I'm probably thinking too much GTK-like), actually I am not
even sure if it could be easily applied at GTK. It would probably just move the
front-end-specifics problem to another area so that's why I have abandoned this
approach and chosen the first one, leaving it here just for order.
Once this part is clarified there are other issues which probably will need
addressing, due to the code changes the new implementation of frames would
entail like the history handling as an example.
14 years, 8 months
Re: r7003 chris_y - /trunk/netsurf/desktop/browser.c
by Daniel Silverstone
On Tue, 2009-03-31 at 06:39 +0000, netsurf(a)semichrome.net wrote:
> Ensure buffer is big enough for the extra character.
> - url_buf = malloc(len + 2 /* '#' + '\0' */);
> + url_buf = malloc(len + 3 /* '#' + '\0' */);
This feels wrong. I'm going to have a poke at the function.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
14 years, 8 months
Re: r7004 struggleyb - /branches/struggleyb/domts-transform-perl/DOMTSHandler.pm
by Daniel Silverstone
On Tue, 2009-03-31 at 10:15 +0000, netsurf(a)semichrome.net wrote:
> +our %special = (
> + # Some of the type are not defined now!
> + boolean => "int ",
bool please :-) We do use stdbool in NetSurf projects.
> + DOMString => "dom_string *",
Out of interest, should we be porting libdom to libwapcaplet to allow
for faster node name comparison etc when we start to need to apply
libcss to libdom? I believe hubbub will be migrating to libwapcaplet
too.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
14 years, 8 months
Re: r7001 chris_y - /trunk/netsurf/desktop/browser.c
by John-Mark Bell
On Mon, 2009-03-30 at 18:10 +0000, netsurf(a)semichrome.net wrote:
> Author: chris_y
> Date: Mon Mar 30 13:10:16 2009
> New Revision: 7001
>
> URL: http://source.netsurf-browser.org?rev=7001&view=rev
> Log:
> Stop URL bar losing characters on every refresh
>
> Modified:
> trunk/netsurf/desktop/browser.c
>
> Modified: trunk/netsurf/desktop/browser.c
> URL: http://source.netsurf-browser.org/trunk/netsurf/desktop/browser.c?rev=700...
> ==============================================================================
> --- trunk/netsurf/desktop/browser.c (original)
> +++ trunk/netsurf/desktop/browser.c Mon Mar 30 13:10:16 2009
> @@ -1096,11 +1096,11 @@
> url_buf = malloc(len + 2 /* '#' + '\0' */);
> if (url_buf) {
> if (frag) {
> - snprintf(url_buf, len + 1, "%s#%s", url, frag);
> + snprintf(url_buf, len + 2, "%s#%s", url, frag);
> + *(url_buf + len + 2) = '\0';
Either I'm being stupid, or this now writes one byte past the end of the
buffer.
J.
14 years, 8 months
gsoc: keyboard navigation
by Sid Lee
Hi,
For the last two days I've been playing with netsurf's code. The
building went smoothly and now that I've read the Docs and skimmed through
the source code, I have a very rough idea about the way netsurf is
constructed. The source code tree seems to be manageable for me because of
its modularity.
After reading netsurf's gsoc page, I find the keyboard navigation
project interesting. Though it's probably not hard, it's actually what I had
in mind as a suitable project for a summer holiday. Here's a sketch of what
I'm thinking about(apart from those listed in the idea list):
First, traversing the web page as documented in the idea list as well as
easy manipulation of tabs and web page elements is necessary. I notice in
the current trunk version, tab control already works. Perhaps we need to
focus on 'text input widgets' manipulation: Ctrl-a, Ctrl-z,
Ctrl-backspace... in all 'input widgets'. This feature is handy.
Second, search through the content of the web page. The current version
disables the 'find' menu item in the 'edit' menu. I suppose it's waiting to
be implemented.
Third, navigation between links and inputs by their physical
position(rather than their position in the HTML tree). This perhaps is more
complicated than I imagine.
I was also thinking about user configurable keyboard shortcuts...(vim
mode, emacs mode) etc. But I'm not sure whether those added up would be too
much for me to focus, some of the features I thought about might involve
parts of netsurf that I don't know about. Also unfamiliarity with GUI
libraries could be a huge problem. So, any suggestions or comments(which
feature is impractical, or can be improved...) are welcomed. :-)
By the way, my nick on freenode is sidlae.
14 years, 8 months
