JDevelop IDE
project page
Check out JDevelop news, updates and information home
About JDevelop


JDevelop is an open source IDE written in Java with a strong design prejudice towards performance and a professional looking user interface.

News


April 24, 2002 - Status update

Just to break the lack of posts, here is a status update:

Things haven't been progressing as rapidly as I would have liked for the last 2 weeks or so, but chalk that one up to that thing called RealLife (better known as "Lack-O-Job"). So while I concentrate on that problem JDevelop isn't getting much of my attention (but I still work on it in my free time). This is by no means a permanent situation, JDevelop is my baby and I will always work on it.

The good news is that all the basic controls I set out to make are done and work great under Windows and Linux (I reinstalled it so I could test. And if any of you care, Gentoo is the best distro I've ever used, and that's comming from a RedHat man of 3 years. The whole idea of compiling your ENTIRE SYSTEM with optimizations specifically for your hardware was just too sweet to pass up. The performance difference is noticable and I run a KDE 3.0 desktop.)

Anyway, back to JDevelop stuff, the controls that are done are: Button, CheckBox, RadioButton and Label.

Also worth noting is that the borders are interchangeable between these controls, so you end up with things like the Button class also being a sweet tool bar button with rollover effects as well.

Anyway, that's my update for the time being, I wanted to keep everyone posted. My next adventure will take me into the deep dark forest known as List-control then maybe a static ComboBox control (noneditable) and then back into the bowels of the text component again. This should be fun! :)

April 5, 2002 - Status update

I want to appologize for all the misspellings in my news posts and possibly the page. I type fast and hate going backwards when I have an idea on my mind, to fix sentence structure and spelling. So for the most part you'll just need to bear with my alphabetic retardation. Also, I am aware of my chronic abuse of run-on sentences, this stems from my political views against punctuation :).

GOOD NEWS, the Button (with both beveled and flat borders working with/without rollover effects), CheckBox and RadioButton controls are all done! I added the Label control to the source tree tonight, and implemented most of it. I just need to finish its bounds initialization code and do the painting code.

Progress is going well... next week unforunately will be slow since I have a VERY busy week between work and school. The following week things should pick back up. I always get bursts of inspiration.

April 3, 2002 - Status update

I'm spending all the development time working on the JCL getting the widgets in place. This has been much more time consuming than I thought. Not because its technilogically hard to do, but because I am so particular about clean package layout and clean class hierarchies. I've started from scratch 3 times already just to have the cleanest and nicest code I can produce. If I had done it all with crap code and just done enough to get it to work, I would have probably finished all major widgets within the first week. However, I now have a hierarchy that I am very happy with.

A Button can container nothing, text, icon or both text and icon. If the Button is blank, has text and/or an icon, the Button will attempt to default to the native Windows button size (75x23 pixels). If for some reason the Button cannot attain this size (text too long, icon to big, etc.) it will size itself accordingly to the content as well as the given padding.

If a Button is blank, has text and/or an icon it will default to using a beveled border, drawing a focus rectangle when focused and not using a rollover effect. This of course can be changed via setter methods.

If a Button only contains an icon, it will default to using a flat border, not drawing a focus rectangle and using a rollover effect (since its assumed the button will be used in a toolbar). Once again, this can be changed. Also, icon-only buttons will default to the size of the icon (plus padding) instead of the Windows button size.

Borders are readily interchangeable on any Control in the JCL. You can put rollover beveled borders on a label if you wanted to. (At the moment certain borders expect to be put on certain controls, and for the sake of programming sanity, things might stay like this).

It's also worth noting that borders utilize the Singleton pattern, and therefore no more than one instance of each border will ever exist in the system, regardless of the number of Controls created that use them. This was done to keep a tight grip on memory footprints, as the number of Controls in an IDE can easily get into large numbers.

I am starting work on the radio buttons and checkboxes this evening. By having the Button class done, the radio and checkbox buttons will go a lot faster since I have an outline to work from. Also radio and check buttons do not have a border by default, so I won't need to spend time coding the Look and Feel for them except for the actual check box and radio circle.

After I have these widgets done I'm going to focus work on a ComboBox control, a List control and a Spinner control. I think the first and last mentioned will take me the most time, but who knows it might be a good nights worth of work. I also have to get a Label control done, but that will be the easiest of them all to do, I might do that this afternoon.

As far as the Tree and Table controls are concerned, I'm going to use a JTree and JTable respectively to keep the fundamental functionality there since its already implemented and quite a headache to redo, but I'm going to use HIGHLY customize ground-up implementations of the Models and Views for both of them to optimize performance and memory footprint. I already have a preliminary version of these working with my file explorer (which is quite a bit more of a headache then I every thought it was going to be).

Eventually I would like to implement my own FileDialog, as the AWT one looks great (since its native) but only allows single file selections, while the Swing JFileChooser looks like crap and is sluggish as hell in almost all use cases. The FileDialog will be the most complicated IMO because it requires a myriad of controls to interact with eachother and also have special functionality (such as the tree view in the combo box drop down at the top). I may never get around to this, but who knows what the future holds. I'm having fun implementing all these controls, and will be happy to see them all in action.

March 21, 2002 - JDevelop Package Breakdown...
Some changes were made to the JDevelop source base today and I wanted to explain them here for anyone that is interested.

First off what has happened... I decided to organize the JDevelop source tree into major packages that encapsulate common functionality of JDevelop. I had the following reasons to do this:

  • Source code organization helps with ease of maintenence and ease of understanding for other developers
  • With the packages separated, it will become easier and more managable to deploy updates via an update manager
  • The separated packages can be easily taken out of JDevelop and used in other projects, for example the JCL
  • I can deploy the project as multiple JARs, which will streamline packaging and distribution for me

I am sure there are some other good reasons, but I don't remember them off the top of my head right now. So I'll just get down to the breakdown of each package and what it does/what its for.

net.sourceforge.jdevelop.jcl
JCL - The JCL stands for "JDevelop Control Library". The JCL is essential custom controls written from the ground up to replace the comparable Swing components. All of the JCL controls extends javax.swing.JComponent and therefore are all Swing-compatable for use in UIs with JCL and Swing controls. The JCL was created instead of just using Swing for the following reasons:

  • Speed
  • Memory footprint
  • Tighter control over the look and feel
  • Upgradeability
  • Understanding of controls implementation

net.sourceforge.jdevelop.jel
JEL - The JEL stands for "JDevelop Extension Library". The JEL acts as a test-bed of new technology that I am currently evaluating that might be merged into JDevelop's functionality. Instead of overhauling JDevelop with a new feature before I know how the feature works, I use the JEL as my test ground, by creating individual mini-apps that implement the new feature, and allow me to tweak it and test it until I am satisfied. At that point the technology may or maynot be merged into JDevelop as part of the IDE. These apps are included just for fun. Sometimes I'll create a handy little utility that I think someone else might be able to use, so I'll include it in this library so you can play with it without using JDevelop. As an example, JSourceCounter. A source code counter that I wrote to count the source code of JDevelop and help me keep tabs on its development for the website. I have spent a long time looking for a good free source code counter, and the simple truth is that none exist, so I went ahead and created one. If JSourceCounter eventually gets merged into JDevelop as a project feature, then JSourceCounter may be removed from the JEL to make room for the next little app.

net.sourceforge.jdevelop.jtl
JTL - The JTL stands for "JDevelop Text Library". JDevelop's success as an IDE or even an editor will rely almost soley on the power and flexibility of its text support. Supporting editing and displaying in more ways than just one. The functionality implemented in the text component will become so vast and so fundamental to JDevelop that it only made sense to branch the text support off into its own module.

net.sourceforge.jdevelop.juil
JUIL - The JUIL stands for "JDevelop User Interface Library". The JUIL represents the actual components that will construct JDevelop's UI. This isn't as general as a "Button" that would be in the JCL, these are more specific components such as "Standard Editing Toolbar" or "EditorWindow". This was broken off into its own package because inevitable as these components get created, they could come in handy for other uses in other contexts. Having these components in their own package makes that breakoff easier for interested developers.

That's it for the changes now. I have been hard at work on the JCL controls. I have buttons graphically and somewhat functionally done and they look great. I'm really proud of the IconButton which is ment for Toolbars and such. This button looks/acts much more attractive then typical JButton's on a JToolBar.

Also note that the FAQs page has been updated and a Status page was added.

Well back to work!

March 8, 2002 - New JDevelop site launched!
Well I finally got around to making the website for JDevelop, sorry it took so long. I wanted to wait until JDevelop was ready to edit files before I made this, but realizing that my schedule is so sporadic with work and school, I just decided to crack open VS.NET and get it done so people would have something to look at and I would have something to update (since a lot of progress is being made).

Please NOTE that the statistics on the JDevelop project on Sourceforge are crap. Aparently Sourceforge's statistics reporting backend has been broken for MONTHS now and there doesn't seem to be any work to fix it. Strangly enough, the statistics used to work on my project, and work on some other projects, but now doesn't work on my project anymore. One day I logged in and noticed all my stats were zeroed out, which made me ask SF support immediately what was going on, to which they just closed my request and pointed me to a FAQ that said a lot of other people are having this problem as well. Anyway, there doesn't seem to be a solution down the road, so just ignore the stats on the page.

Webmaster
Valid HTML 4.0! SourceForge.net Logo Valid XHTML 1.0!