Thread: [java-gnome-hackers] sourceview development branch
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
From: Stefan S. <ste...@gm...> - 2009-05-18 11:33:44
|
Hi, the sourceview development branch is now available on launchpad. In case you are interested, you can get it with: bzr branch lp:~stefan-schweizer/+junk/sourceview Or have a look at it here: https://code.launchpad.net/~stefan-schweizer/+junk/sourceview I hope to get it ready to be merged soon. Comments and patches are of course welcome! Stefan |
|
From: Stefan S. <ste...@gm...> - 2009-05-20 20:45:38
|
On Mon, 2009-05-18 at 13:33 +0200, Stefan Schweizer wrote: > the sourceview development branch is now available on launchpad. In case > you are interested, you can get it with: > > bzr branch lp:~stefan-schweizer/+junk/sourceview > > Or have a look at it here: > https://code.launchpad.net/~stefan-schweizer/+junk/sourceview > > I hope to get it ready to be merged soon. Comments and patches are of > course welcome! > I made good progress with that branch over the last days and it would be nice if somebody could review it in more detail. I focused on SourceView and SourceBuffer and exposed the methods that seemed useful for me. I did not touch Styles, Marks and some other things. There is an example editor in sourceview.ExampleEditor.java that showcases the exposed features. Stefan |
|
From: Andrew C. <an...@op...> - 2009-05-20 23:48:26
|
On Wed, 2009-05-20 at 22:45 +0200, Stefan Schweizer wrote:
> I made good progress with that branch over the last days and it would be
> nice if somebody could review it in more detail.
I glanced at it early yesterday and I was quite impressed. It already
seems close to being mergeable which is awesome.
The broader question is whether the API being presented is wise. Because
I'm not [needing to] use this personally it's harder for me to say.
The only thing that really caught my eye so far was
LanguageManager.getDefault(); my *personal* taste is that I dislike
static functions anywhere other than library initialization.
[I find that in the midst of a whole bunch of instance variable
usage that they seem out of place. This is why a)
Screen.getDefault() is still quiet and b) various functions are
exposed as static methods on classes Glib, Gtk, and Glade]
But a function is a function and this probably the best way to expose
it. I welcome anyone to suggest alternative ideas.
Other than that, my first impression is that this looks great. I'll pull
your latest work later today I'll have a proper review then, but we will
definitely feature this in 4.0.12 :)
AfC
Sydney
|
|
From: Stefan S. <ste...@gm...> - 2009-05-21 08:04:13
|
On Thu, 2009-05-21 at 09:48 +1000, Andrew Cowie wrote: > The only thing that really caught my eye so far was > LanguageManager.getDefault(); my *personal* taste is that I dislike > static functions anywhere other than library initialization. Another option would be to turn LanguageManager into a real singleton and only call that function when the singleton instance is created. The LanguageManager would then be accessed like this: LanguageManager.getInstance(); that does not remove the static method but would make it more explicit that you are using one. Maybe that would fit better? |
|
From: Andrew C. <an...@op...> - 2009-05-22 14:31:41
|
On Wed, 2009-05-20 at 22:45 +0200, Stefan Schweizer wrote: > There is an example editor in sourceview.ExampleEditor.java that > showcases the exposed features. A few of us tried running the Example, but it threw Exception in thread "main" java.lang.NullPointerException at sourceview.ExampleEditor.updateButtons(ExampleEditor.java:156) at sourceview.ExampleEditor.<init>(ExampleEditor.java:79) at sourceview.ExampleEditor.main(ExampleEditor.java:186) I assume it works for you, so we'll need some help to figure that out. AfC Sydney |
|
From: Stefan S. <ste...@gm...> - 2009-05-22 18:32:48
|
On Fri, 2009-05-22 at 23:31 +1000, Andrew Cowie wrote: > A few of us tried running the Example, but it threw > > Exception in thread "main" java.lang.NullPointerException > at > sourceview.ExampleEditor.updateButtons(ExampleEditor.java:156) > at sourceview.ExampleEditor.<init>(ExampleEditor.java:79) > at sourceview.ExampleEditor.main(ExampleEditor.java:186) > > > I assume it works for you, so we'll need some help to figure that out. Sorry! That of course never worked. I just pushed a fix to the development branch. Stefan |
|
From: Andrew C. <an...@op...> - 2009-05-23 08:37:49
|
On Thu, 2009-05-21 at 10:03 +0200, Stefan Schweizer wrote:
> On Thu, 2009-05-21 at 09:48 +1000, Andrew Cowie wrote:
> > The only thing that really caught my eye so far was
> > LanguageManager.getDefault(); my *personal* taste is that I dislike
> > static functions anywhere other than library initialization.
>
> Another option would be to turn LanguageManager into a real singleton
> and only call that function when the singleton instance is created. The
> LanguageManager would then be accessed like this:
> LanguageManager.getInstance(); that does not remove the static method
> but would make it more explicit that you are using one. Maybe that would
> fit better?
Nah, not really.
The whole "here's a class which has a factory method which you use to
get the only instance of the class which you then use to lookup an item
in the group that that class manages" thing is fairly common Java and
what I hate so much about most Java libraries. I'm a bit saddened to see
that we're forced to deal with this coming from a GNOME library.
Oh well.
++
As I was reading through this branch this afternoon, I noticed that you
don't have a no-arg SourceBuffer constructor.
So here's something you might look at: punch up TextBuffer and TextTag
have a look at how we able to avoid people having to use TextTagTables
if they don't really feel like it.
Because
buffer.setLanguage(LanguageManager.getDefault().getLanguage("java"));
is moderately horrid, even when written more clearly as
manager = LanguageManager.getDefault()
java = manager.getLanguage("java");
buffer.setLanguage(java);
it still seems a lot of work.
[Admittedly GUI programming is always a lot of work, but nevertheless]
The real question that is bothering me is "would you ever have any
reason to have a LanguageManager other than the default one?" My guess
is no.
So let's see.
Normally I'm pretty obsessive about strong typing, and the idea of
strongly-typed Language instances seems fine. Fair bit of work to get
at, as we've seen. So part of me wonders if we couldn't compress that a
bit.
If it wasn't for the fact that I just asserted how important strong type
safety is, I'd almost be tempted to suggest:
buffer.setLanguage("java");
but... no.
Hm.
Dare I suggest preconfigured constants, ie Language.JAVA maybe? See
org.gnome.gtk's PaperSize.A4 and friends. So have a look at that, have a
look at the no-arg TextTag() and no-arg TextBuffer() constructors. While
you're at it, see org.gnome.gtk's Statusbar for an example of where we
just engineered around something that was silly.
See if any of these spawn any bright ideas.
[obviously the risk with preconfigured constants is we don't want to
force GtkSourceView to load all kinds of stuff if we aren't going to
need it, and initializing constants has a tendency to do that unless
you're careful about being lazy]
++
Weighing against all of this is "we only diverge the API mapping if
we've got a good reason to" but avoiding intermediate factory classes
that don't do anything are in the category of good reason, IMHO.
Failing all that, it seems like the static method could simply be on
Language, leaving LanguageManager out of it entirely. Again - if there's
more purpose for that class, fine, but it sure doesn't seem that way.
++
Other than this API question, the branch is in *excellent* shape and I
am prepared to accept it into java-gnome. Fantastic work.
AfC
Sydney
--
Andrew Frederick Cowie
Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.
http://www.operationaldynamics.com/
Sydney New York Toronto London
|
|
From: Serkan K. <se...@ge...> - 2009-05-23 12:07:55
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Cowie yazmış:
I don't know how common it is but users are always able to add custom
language definitions. Predefining constants for languages will hinder
this extensibility.
> Normally I'm pretty obsessive about strong typing, and the idea of
> strongly-typed Language instances seems fine. Fair bit of work to get
> at, as we've seen. So part of me wonders if we couldn't compress that a
> bit.
>
> If it wasn't for the fact that I just asserted how important strong type
> safety is, I'd almost be tempted to suggest:
>
> buffer.setLanguage("java");
>
> but... no.
>
> Hm.
>
> Dare I suggest preconfigured constants, ie Language.JAVA maybe? See
> org.gnome.gtk's PaperSize.A4 and friends. So have a look at that, have a
> look at the no-arg TextTag() and no-arg TextBuffer() constructors. While
> you're at it, see org.gnome.gtk's Statusbar for an example of where we
> just engineered around something that was silly.
>
> See if any of these spawn any bright ideas.
>
> [obviously the risk with preconfigured constants is we don't want to
> force GtkSourceView to load all kinds of stuff if we aren't going to
> need it, and initializing constants has a tendency to do that unless
> you're careful about being lazy]
- --
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoX5xIACgkQRh6X64ivZaIR6wCfUCyU71JNun2ZTshCn3uKKd2c
iccAn2Zu2siqLvdBTi3xrHg5Fw6sR+kX
=POPh
-----END PGP SIGNATURE-----
|
|
From: Andrew C. <an...@op...> - 2009-05-23 14:24:53
|
On Sat, 2009-05-23 at 15:07 +0300, Serkan Kaba wrote: > Predefining constants for languages will hinder > this extensibility. Only if developers can't create their own constants. Which is exactly what they *can* do with Stock, Keyval, etc. AfC Sydney |
|
From: Stefan S. <ste...@gm...> - 2009-05-23 15:57:04
|
On Sat, 2009-05-23 at 18:37 +1000, Andrew Cowie wrote: > As I was reading through this branch this afternoon, I noticed that > you > don't have a no-arg SourceBuffer constructor. Yes, a no-arg constructor would be nice. Will have a look at that. > Dare I suggest preconfigured constants, ie Language.JAVA maybe? See > org.gnome.gtk's PaperSize.A4 and friends. I am not sure about the constants. GtkSourceView supports 70 languages or so and they may not always be available because the search path can be changed. There is a method to do that in LanguageManager (not exposed yet). This could be useful for special-purpose language files that are shipped with a java-gnome application. > Weighing against all of this is "we only diverge the API mapping if > we've got a good reason to" but avoiding intermediate factory classes > that don't do anything are in the category of good reason, IMHO. > > Failing all that, it seems like the static method could simply be on > Language, leaving LanguageManager out of it entirely. Again - if > there's > more purpose for that class, fine, but it sure doesn't seem that way. There are more things in LanguageManager that I did not (yet?) expose: the already mentioned method to change the search path for language files and there is a method to guess the language from a given file. So, I do not think LanguageManager is useless. Stefan |
|
From: Stefan S. <ste...@gm...> - 2009-05-24 09:26:39
|
On Sat, 2009-05-23 at 17:56 +0200, Stefan Schweizer wrote: > On Sat, 2009-05-23 at 18:37 +1000, Andrew Cowie wrote: > > As I was reading through this branch this afternoon, I noticed that > > you > > don't have a no-arg SourceBuffer constructor. > > Yes, a no-arg constructor would be nice. Will have a look at that. I just added that constructor. To do that, I added an additional constructor to TextBuffer and made TextTagTable.getDefaultTable() public. I hope that's OK. |
|
From: Andrew C. <an...@op...> - 2009-05-25 02:22:49
|
On Sun, 2009-05-24 at 11:26 +0200, Stefan Schweizer wrote: > > Yes, a no-arg constructor would be nice. Will have a look at that. > > I just added that constructor. To do that, I added an additional > constructor to TextBuffer and made TextTagTable.getDefaultTable() > public. I hope that's OK. I have long wished that Java had a "library" visibility between public and package. Oh well. So what you did worked, but instead I think we'll keep it out of public by moving getDefaultTable() from TextTagTable to TextBuffer and making protected there so SourceBuffer can see it. I've done this; see 'hackers/andrew/sourceview'. ++ I'm going to play with some strongly typed constants a bit, to see if I can come up with an idiom that doesn't seem too out of control, but other than that, this branch is acceptable for merging. AfC Sydney |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X