jedit-devel Mailing List for jEdit

Bugs item #1955173, was opened at 2008-05-01 01:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1955173&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: severe bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marcello Teodori (mteodori)
Assigned to: Nobody/Anonymous (nobody)
Summary: jEdit does not start on Leopard with Java 1.6 as default

Initial Comment:
When setting 1.6 as default JVM, jEdit does not start because the MacOS integration plugin is incompatible with the released 1.6 JVM from Apple as it does not contain the Cocoa-Java bridge which had been deprecated in 1.5.

Everything is ok if I remove the plugin file: jEdit.app/Contents/Resources/Java/jars/MacOS.jar
until a version not using the Cocoa-Java bridge is available.






----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1955173&group_id=588

Bugs item #1955140, was opened at 2008-04-30 23:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1955140&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hypersearch dockable - shortcut fails

Initial Comment:
I have assigned ESCAPE as shortcut to the action "close-docking-area". For most dockables it works fine. But it doesn't close the Hypersearch dockable if it has the keyboard focus (immediately after the search).

After clicking a search result the keyboard focus moves to the textarea and ESCAPE closes the Hypersearch dockable.

(related to #1404379 ?)

jEdit 4.3pre14
Sun JRE 1.6.0_05
WinXP SP2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1955140&group_id=588

The reason I suggested using the SQL Plugin as a dependency was because it
already has some things Shlomy might have to otherwise implement himself.

The user can create a SQL Server Configuration for their project - using the
configuration panel, and the CTagsInterface can then use that
database/server name to store it's data. I just figured it would be easier
to use the SQL plugin since it already has the UI, persistence (of the
settings) capabilities and project specific set up. It's one less thing
Shlomy would have to do himself.

On Wed, Apr 30, 2008 at 2:00 AM, Matthieu Casanova <cho...@gm...>
wrote:

> On Wed, Apr 30, 2008 at 10:54 AM, Shlomy Reinstein <sre...@gm...>
> wrote:
> > >  Maybe instead of using the sql plugin and a jdbc driver there should
> >  >  be a layer between them and your CtagsInterface depends on a Data
> >  >  plugin that would have methods to get your tags. And it is his job
> to
> >  >  do what is necessary (sql queries for example).
> >  >  But it is more work...
> >  >
> >
> >  What is the difference between the Data plugin that you suggest here
> >  and the SQL plugin?
>
> It depends about what you are talking about when talking of a SQL
> plugin dependency.
> What I mean is that the sql queries should not be in the CtagsInterface
> plugin
>
> Matthieu
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>



-- 
Learn from the past. Live in the present. Plan for the future.
11101000

Bugs item #1954921, was opened at 2008-04-30 09:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954921&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: virtual file systems
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: file:// URIs in windows

Initial Comment:
http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx

I wanted to test some file:/// uris in windows, such as this one, which should be valid according to the above document (assuming you have cygwin doctools installed)

file:///c:/cygwin/usr/share/xml/docbook/4.2/
However, it does not get properly interpreted when I paste it into the Path: history text field of the FSB.

Reports "cannot list directory"

jedit 4.3pre14





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954921&group_id=588

>  Hi, I think there can be some problems when using the SQL plugin,
>  because SQL is not always 100% portable, so switching to another
>  database may not work perfectly with exactly the same queries.
>

Right. I've just made (locally) the changes in CtagsInterface for
using h2 instead of hsqldb. I was amazed by the ease in which I could
switch to h2, but I did notice that hsqldb uses some non-standard SQL
statements, e.g. "create cached table". I think it's worth getting rid
of the non-standard statements to allow flexibility in database driver
selection, and the non-standard SQL statements can in some way be
configured by the user (I need to think how to do that).

I think I will add an option to the plugin to specify the JDBC driver
and connection, and commit them to SVN. In order to work out of the
box, I can continue to include one of the DBs with CtagsInterface and
set the default values of these options to use it.

Shlomy

>  Maybe instead of using the sql plugin and a jdbc driver there should
>  be a layer between them and your CtagsInterface depends on a Data
>  plugin that would have methods to get your tags. And it is his job to
>  do what is necessary (sql queries for example).
>  But it is more work...
>

What is the difference between the Data plugin that you suggest here
and the SQL plugin?

Bugs item #1954020, was opened at 2008-04-29 11:20
Message generated for change (Comment added) made by scarlac
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954020&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: will69 (will69)
Assigned to: Seph M. Soliman (scarlac)
Summary: icon spacing with Nimbus L&F

Initial Comment:
Icons (bath tango and classic) have very wide spacing when using the new Nimbus L&F. This wasn't the case before 4.3pre14. You can try Nimbus L&F by downloading JRE 6u10 from http://download.java.net/jdk6/.

----------------------------------------------------------------------

>Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-30 16:22

Message:
Logged In: YES 
user_id=831311
Originator: NO

I'll post my mail to will69 as it will probably be useful for others as
well:

Mail snip: (...)

I got JDK 6u10 installed locally on linux and just did some testing.

Setting preferredSize did the trick but with the sacrifice that the
buttons must be enlarged to 32x32 pixels, so the Metal buttons will be
slighty larger. The good news is that Gtk+ buttons are slightly smaller and
Nimbus buttons are signifigantly smaller. Due to shadowing-effects, the
buttons will be rendered slighty larger/smaller on each L&F, but this isn't
something I would fix as it would be too L&F-specific.

As for the rest of jEdit and Nimbus there are still a lot of issues if it
is released as-is when u10 comes out. Icons on tabs are shiftet, vertical
sidebar buttons are way too wide and other issues plague Nimbus with jEdit
as well.

(...)

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2008-04-30 16:17

Message:
Logged In: YES 
user_id=285591
Originator: NO

Thanks for fixing that. In the same kind, do you have an idea why the
buttons of the dockable panels are so big with Nimbus ?

----------------------------------------------------------------------

Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-30 01:37

Message:
Logged In: YES 
user_id=831311
Originator: NO

A fix has been commited to rev. 12526 which sets all toolbar buttons to
32x32.

----------------------------------------------------------------------

Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-29 14:17

Message:
Logged In: YES 
user_id=831311
Originator: NO

Issue confirmed. This is a general spacing problem with the Numbus L&F
which adds uncontrollable padding to buttons to make them look "nicer".

As you might have noticed with other L&F they usually don't include much
padding inside regular buttons. The reason for the change since Pre14 is
that the new version includes a fix that enables L&F-specific button
outlines to appear in the toolbar rather than a fixed etched one. The fix
was made to give a smoother look with Metal, GTK+ and Windows (Classic)
L&F.

A possible fix to this issue is to rewrite the entire toolbar code to the
native Swing JToolBar, but for now i'm rejecting this ticket. I belive
there was some specific reasons not to use the jtoolbar.

Regards,
Seph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954020&group_id=588

Bugs item #1954020, was opened at 2008-04-29 11:20
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954020&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: will69 (will69)
Assigned to: Seph M. Soliman (scarlac)
Summary: icon spacing with Nimbus L&F

Initial Comment:
Icons (bath tango and classic) have very wide spacing when using the new Nimbus L&F. This wasn't the case before 4.3pre14. You can try Nimbus L&F by downloading JRE 6u10 from http://download.java.net/jdk6/.

----------------------------------------------------------------------

>Comment By: Matthieu Casanova (kpouer)
Date: 2008-04-30 16:17

Message:
Logged In: YES 
user_id=285591
Originator: NO

Thanks for fixing that. In the same kind, do you have an idea why the
buttons of the dockable panels are so big with Nimbus ?

----------------------------------------------------------------------

Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-30 01:37

Message:
Logged In: YES 
user_id=831311
Originator: NO

A fix has been commited to rev. 12526 which sets all toolbar buttons to
32x32.

----------------------------------------------------------------------

Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-29 14:17

Message:
Logged In: YES 
user_id=831311
Originator: NO

Issue confirmed. This is a general spacing problem with the Numbus L&F
which adds uncontrollable padding to buttons to make them look "nicer".

As you might have noticed with other L&F they usually don't include much
padding inside regular buttons. The reason for the change since Pre14 is
that the new version includes a fix that enables L&F-specific button
outlines to appear in the toolbar rather than a fixed etched one. The fix
was made to give a smoother look with Metal, GTK+ and Windows (Classic)
L&F.

A possible fix to this issue is to rewrite the entire toolbar code to the
native Swing JToolBar, but for now i'm rejecting this ticket. I belive
there was some specific reasons not to use the jtoolbar.

Regards,
Seph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954020&group_id=588

Matthieu Casanova wrote:
> On Tue, Apr 29, 2008 at 9:13 PM, Shlomy Reinstein
> <sre...@gm...> wrote:
>> Sounds like a good idea, but first ... Can the SQL plugin
>> work with in-memory or cached tables? Is there a way to

Shlomy,

in my experience the database schema is typically far less 
cross-db-engine capable than "good" SQL queries/code.

Chances are the cross-db approach will have to rely on db schema 
scripts for every db engine.

An additional abstraction layer sounds like a good idea to make 
it easier to implement support for less standardized, less 
SQL-ish database systems, and to lay the basis for supporting 
other implementations with less hacking, too. (I guess you 
already more or less almost have that with your existing 
structure, having all methods for accessing the tag db in one 
class (IIRC).



Bye bye

On Tue, Apr 29, 2008 at 9:13 PM, Shlomy Reinstein <sre...@gm...> wrote:
>  Sounds like a good idea, but first ... Can the SQL plugin work with
>  in-memory or cached tables? Is there a way to configure the underlying
>  database?
>  And, most importantly, do you know how much work switching to SQL
>  plugin requires? I didn't see any documentation for coding with it.

Hi, I think there can be some problems when using the SQL plugin,
because SQL is not always 100% portable, so switching to another
database may not work perfectly with exactly the same queries.

Matthieu

Patches item #1954810, was opened at 2008-04-30 15:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1954810&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal Sancho (psancho)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for XSLT mode ('value' attribute)

Initial Comment:
xsl:number/@value attribute content should be formatted as xsl:value-of/@select attribute. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1954810&group_id=588

On Wed, Apr 30, 2008 at 10:54 AM, Shlomy Reinstein <sre...@gm...> wrote:
> >  Maybe instead of using the sql plugin and a jdbc driver there should
>  >  be a layer between them and your CtagsInterface depends on a Data
>  >  plugin that would have methods to get your tags. And it is his job to
>  >  do what is necessary (sql queries for example).
>  >  But it is more work...
>  >
>
>  What is the difference between the Data plugin that you suggest here
>  and the SQL plugin?

It depends about what you are talking about when talking of a SQL
plugin dependency.
What I mean is that the sql queries should not be in the CtagsInterface plugin

Matthieu

Bugs item #1954760, was opened at 2008-04-30 08:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954760&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam R (mlecomte)
Assigned to: Nobody/Anonymous (nobody)
Summary: Absolute value is not computed correctly

Initial Comment:
On line 85 of the EditServer class of org.gjt.sp.jedit is this code:

authKey=Math.abs(new Random().nextInt());

If the number returned by the random number generator is Integer.MIN_VALUE, then the result will be negative as well (since Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954760&group_id=588

On Wed, Apr 30, 2008 at 10:41 AM, Shlomy Reinstein <sre...@gm...> wrote:
> >  Hi, I think there can be some problems when using the SQL plugin,
>  >  because SQL is not always 100% portable, so switching to another
>  >  database may not work perfectly with exactly the same queries.
>  >
>
>  Right. I've just made (locally) the changes in CtagsInterface for
>  using h2 instead of hsqldb. I was amazed by the ease in which I could
>  switch to h2, but I did notice that hsqldb uses some non-standard SQL
>  statements, e.g. "create cached table". I think it's worth getting rid
>  of the non-standard statements to allow flexibility in database driver
>  selection, and the non-standard SQL statements can in some way be
>  configured by the user (I need to think how to do that).
>
>  I think I will add an option to the plugin to specify the JDBC driver
>  and connection, and commit them to SVN. In order to work out of the
>  box, I can continue to include one of the DBs with CtagsInterface and
>  set the default values of these options to use it.

Maybe instead of using the sql plugin and a jdbc driver there should
be a layer between them and your CtagsInterface depends on a Data
plugin that would have methods to get your tags. And it is his job to
do what is necessary (sql queries for example).
But it is more work...

Jesse Pavel wrote:
> Hi Shlomy,
> 
> If the problem is related to the backup replication of the
> large DB, you could try building a custom HSQLDB by first
> changing the backupFile() and renameBackupFile() methods to
> no-ops in DataFileCache.java (starting at line 638) in the
> HSQLDB source. It seems silly that they didn't include a user
> option, so far as I can see, to avoid ZIP'ing hundreds of
> megabytes on every shutdown.
> 
> I'm not sure that would solve the problem, or if you'd want
> to get that involved in the DB, but it may be an idea.

Jesse,

being a solution that can be tested in what seems like minutes, 
I'd definitely take this route, if only as a first step for 
analysis or further changes towards another db engine or db 
interface. I'd probably try to find the spot for the HSQLDB JDBC 
URL parsing and add a custom option there. (All that assuming 
that I am not missing something about this seemingly odd 
mechanism in HSQLDB. I have a gut feeling that this cannot 
really be how the creators meant it to behave, but oh well.)

Bye bye

Shlomy Reinstein wrote:
>>> Shouldn't it be an advanced configuration option to
>>> choose a different, supported database, specifying URL,
>>> login, etc. for that?
>> 
>> Yes, with JDBC, it should be possible to write
>> CtagsInterfacePlugin to use a different back-end instead of
>> hsqldb. That way, people can use the built-in java DB for
>> small simple situations, or on windows when one does not
>> wish to install postgres.
> 
> Actually, you're right. I think I can easily add an option to
>  CtagsInterface for users to pick the JDBC driver and
> connection details, it's a very good idea. Eric also
> suggested that I create a dependency on the SQL plugin,
> allowing the user to pick the DB using the SQL plugin
> options. What do you think is better? Does the later (using
> SQL plugin) have advantages over a simply driver/connection 
> option in CtagsInterface?

Shlomy,

admittedly my first knee jerk reaction to mandatorily depending 
on the SQL plugin was "no, too brittle, too many layer, likely 
to be more complicated for developer and end user than it should 
be".

Bye bye

>  >  Shouldn't it be an advanced configuration option to choose a
>  >  different, supported database, specifying URL, login, etc. for that?
>
>  Yes, with JDBC, it should be possible to write CtagsInterfacePlugin to
>  use a different
>  back-end instead of hsqldb. That way, people can use the built-in java
>  DB for small simple situations, or on windows when one does not wish
>  to install postgres.

Actually, you're right. I think I can easily add an option to
CtagsInterface for users to pick the JDBC driver and connection
details, it's a very good idea. Eric also suggested that I create a
dependency on the SQL plugin, allowing the user to pick the DB using
the SQL plugin options. What do you think is better? Does the later
(using SQL plugin) have advantages over a simply driver/connection
option in CtagsInterface?

Shlomy

Bugs item #1954464, was opened at 2008-04-29 14:06
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954464&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
>Assigned to: Seph M. Soliman (scarlac)
Summary: Toolbar Option Pane: Edit Button unvisible

Initial Comment:
In GlobalOptions->Toolbar the Edit button is unvisible (there is no icon). When hovering with the mouse the button will be visible - but very small.


----------------------------------------------------------------------

Comment By: Robert Schwenn (rschwenn)
Date: 2008-04-29 14:09

Message:
Logged In: YES 
user_id=1486645
Originator: YES

forgotten:

jEdit 4.3pre14
WinXP


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954464&group_id=588

>  Hello Shlomy,
>
>  thanks for clarifying this for me.
>
>  Shouldn't it be an advanced configuration option to choose a
>  different, supported database, specifying URL, login, etc. for that?

Yes, with JDBC, it should be possible to write CtagsInterfacePlugin to
use a different
back-end instead of hsqldb. That way, people can use the built-in java
DB for small simple situations, or on windows when one does not wish
to install postgres.

>
>  For Windows users even MySQL might be an "easier" choice than
>  PostgreSQL with the non-admin login requirement I mentioned.

Yes, that too!

Bugs item #1954020, was opened at 2008-04-29 11:20
Message generated for change (Comment added) made by scarlac
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954020&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: will69 (will69)
Assigned to: Seph M. Soliman (scarlac)
Summary: icon spacing with Nimbus L&F

Initial Comment:
Icons (bath tango and classic) have very wide spacing when using the new Nimbus L&F. This wasn't the case before 4.3pre14. You can try Nimbus L&F by downloading JRE 6u10 from http://download.java.net/jdk6/.

----------------------------------------------------------------------

>Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-30 01:37

Message:
Logged In: YES 
user_id=831311
Originator: NO

A fix has been commited to rev. 12526 which sets all toolbar buttons to
32x32.

----------------------------------------------------------------------

Comment By: Seph M. Soliman (scarlac)
Date: 2008-04-29 14:17

Message:
Logged In: YES 
user_id=831311
Originator: NO

Issue confirmed. This is a general spacing problem with the Numbus L&F
which adds uncontrollable padding to buttons to make them look "nicer".

As you might have noticed with other L&F they usually don't include much
padding inside regular buttons. The reason for the change since Pre14 is
that the new version includes a fix that enables L&F-specific button
outlines to appear in the toolbar rather than a fixed etched one. The fix
was made to give a smoother look with Metal, GTK+ and Windows (Classic)
L&F.

A possible fix to this issue is to rewrite the entire toolbar code to the
native Swing JToolBar, but for now i'm rejecting this ticket. I belive
there was some specific reasons not to use the jtoolbar.

Regards,
Seph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954020&group_id=588

Bugs item #1954464, was opened at 2008-04-29 23:06
Message generated for change (Comment added) made by rschwenn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954464&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Toolbar Option Pane: Edit Button unvisible

Initial Comment:
In GlobalOptions->Toolbar the Edit button is unvisible (there is no icon). When hovering with the mouse the button will be visible - but very small.


----------------------------------------------------------------------

>Comment By: Robert Schwenn (rschwenn)
Date: 2008-04-29 23:09

Message:
Logged In: YES 
user_id=1486645
Originator: YES

forgotten:

jEdit 4.3pre14
WinXP


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954464&group_id=588

Bugs item #1954464, was opened at 2008-04-29 23:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954464&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Toolbar Option Pane: Edit Button unvisible

Initial Comment:
In GlobalOptions->Toolbar the Edit button is unvisible (there is no icon). When hovering with the mouse the button will be visible - but very small.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1954464&group_id=588

On Tue, Apr 29, 2008 at 12:13 PM, Shlomy Reinstein <sre...@gm...>
wrote:

> > One suggestion which may make this the DB implementation easier to
> choose.
> > Why not use the SQL plugin as a dependency? This way you can let users
> > decide which database they want to use by setting it up in the SQL
> plugin,
> > then your plugin can use it to get connections and execute SQL etc... As
> > long as you stick to standard SQL there shouldn't be any problems
> between
> > the different databases.
> >
> > Then you can include any Java DB for users out of the box, but say that
> if
> > they'd like better performance they should use a different one.
> >
>
> Sounds like a good idea, but first ... Can the SQL plugin work with
> in-memory or cached tables? Is there a way to configure the underlying
> database?


It shouldn't be that hard since the SQL plugin just provides the gateway to
run sql statements (from text). There's already a server type definition for
derby, it shouldn't be hard to make one for hsqldb.


>
> And, most importantly, do you know how much work switching to SQL
> plugin requires? I didn't see any documentation for coding with it.
>

It's pretty easy in the context of jEdit.
[code]
// gets you the SqlServerRecord for the current project, with the given
serverName.
SqlServerRecord rec = SqlUtils.getServerRecord(SqlUtils.getProject(view),
serverName);

// gets you a new db connection to the above server.
Connection conn = sqlServerRecord.allocConnection();
[/code]

>From there it's standard jdbc to execute queries and such.

I used it once in a macro, should be ok in a plugin.

Hope that helps,
Eric

-- 
Learn from the past. Live in the present. Plan for the future.
11101000

Plugin Bugs item #1873116, was opened at 2008-01-16 19:41
Message generated for change (Comment added) made by rschwenn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1873116&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: LogViewer: Initilializing problem

Initial Comment:
Steps to reproduce:

1. Be surethat that the LogViewer has at least 1 file to view and the plugin's dockable is docked
2. Restart jEdit

3. Open the LogViewer's dockable => it's empty!

4. Go to another dockable in the same dockarea
5. Go back to the LogViewer's dockable => now it's ok and shows somthing.

This is the easiest way to get the LogViewer working for me. If the dockable is not docked it's more diffcult.


WinXP SP2
Sun JRE 1.6.0_03
jEdit 4.3pre12
LogViewer Plugin 0.6


----------------------------------------------------------------------

>Comment By: Robert Schwenn (rschwenn)
Date: 2008-04-29 21:37

Message:
Logged In: YES 
user_id=1486645
Originator: YES

This issue does only occur as long as there has no buffer been loaded.

WinXP SP2
Sun JRE 1.6.0_05
jEdit 4.3pre14
LogViewer Plugin 0.6

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1873116&group_id=588

> One suggestion which may make this the DB implementation easier to choose.
> Why not use the SQL plugin as a dependency? This way you can let users
> decide which database they want to use by setting it up in the SQL plugin,
> then your plugin can use it to get connections and execute SQL etc... As
> long as you stick to standard SQL there shouldn't be any problems between
> the different databases.
>
> Then you can include any Java DB for users out of the box, but say that if
> they'd like better performance they should use a different one.
>

Sounds like a good idea, but first ... Can the SQL plugin work with
in-memory or cached tables? Is there a way to configure the underlying
database?
And, most importantly, do you know how much work switching to SQL
plugin requires? I didn't see any documentation for coding with it.