Re: Future of JavaHelp (or a replacement) in NetBeans?
Jep, agree. I also tried DocBook and broke my neck on it. Did cost too much time. Too keep it simply we could go with the standard Online help but with an offline option so the help can be read if not connected. Conversion would be minimal as one "only" would need to migrate the control XML files deciding the book order (topics etc.) but most of the core text stays the same as they already are in HTML. Bernd On 9/23/2018 8:55 AM, Tim Boudreau wrote: On Sun, Sep 23, 2018 at 5:18 AM Oliver Rettig wrote: Hi Jan, this sound interesting for me. In the past I have also thought about DocBook Having written two books using DocBook, one word: Don't. Something simple and text-based, especially something you can fill the gaps in with HTML markup if you've just GOT to do something fancy, is more than enough. Markdown or one of the many cousins it has is simple and noise free. With DocBook, on the other hand, you get - A gargantuan DTD you have to pick a subset of to keep your sanity, and then police that uses stay within that subset - you don't need something that includes every subvariant of a footnote or endnote ever invented for an academic paper - Last time I dealt with it, there were no Java XML parsers that could actually handle the stylesheets - Markup that is far less suggestive of what the end result is going to look like You could do most of the structuring of help with a simple convention for naming and nestling subfolders, with a very simple markup language. DocBook for this is kind of like launching an aircraft carrier to swat a fly. -Tim . Can you share the XSLT stylesheets to get an idea how it works and how looks? There exist some ant tasks http://ant4docbook.sourceforge.net/ maybe based on we can create some default procedure to integreate help into our platform apps. At the moment I also use docuwiki to make documentation for my patform apps availble: http://upperlimb.orat.de/doku.php There is a plugin to create the tox.xml and map.xml file from java-help https://github.com/i-net-software/dokuwiki-plugin-siteexport So at the moment I create my documentation by dokuwiki ant than I create my java-help based on this. The advantage is that some custumers inclusive me can easy write together on the documentation and from time to time I update ma java-doc from this. Any ideas are welcome:-) best regards Oliver Btw, not NB related, we switched from JavaHelp to a set of static HTML pages (generated using custom XSLT stylesheets from DocBook XML source): + no internet access is required + preserving context help linking + easier styling + responsive layout - limited search capabilities (keywords processed by lucene are exported into simple text file, no complex queries can be used) That search can be hardly improved without serving HTML pages via local webserver (which was rejected by lead developers). Without webserver there are many security constraints like inability to load external content dynamically or problematic cookie/local storage management. We also publish same document to online CMS portal, here with the full search capabilities. It is available there as a set of pages with advanced navigation (outline, breadcrumbs, prev/next buttons), but also as a single PDF file (which is stil requested by many users - it can be stored as single file and printed easily). These outputs we produce again from single DocBook XML source. It is up to the user if he choose online/offline (context) help. The default option is online help. That offline variant is considered as a fallback in case of none or poor internet connection. Jan -Original Message----- From: Bernd Ruehlicke Sent: Saturday, September 22, 2018 5:22 PM To: dev@netbeans.incubator.apache.org Subject: Re: Future of JavaHelp (or a replacement) in NetBeans? Uh ... my application is often used in areas without any network connection. Even though the UI is not the most beautiful in the world it is a very helpful tool and I use JavaHelp quite extensively. Of course I am in line with Time, a chance is needed but we should have the case in mind for off-line users. With JavaHelp I like that it is integrated to my application and not some website - it ships with it integrated nicely. This could of course be solve easy by simply add a Help->Update Offline Help and it simply dumps the current online help to disk for offline usage. Maybe even automatically avoiding a menu item, using the same idea as the Update Server that on startup the app is checking of the online documentation has been updated and pops up a suggestion to the user to "Want to update offline documentation", i.e. the online help
Re: Future of JavaHelp (or a replacement) in NetBeans?
Uh ... my application is often used in areas without any network connection. Even though the UI is not the most beautiful in the world it is a very helpful tool and I use JavaHelp quite extensively. Of course I am in line with Time, a chance is needed but we should have the case in mind for off-line users. With JavaHelp I like that it is integrated to my application and not some website - it ships with it integrated nicely. This could of course be solve easy by simply add a Help->Update Offline Help and it simply dumps the current online help to disk for offline usage. Maybe even automatically avoiding a menu item, using the same idea as the Update Server that on startup the app is checking of the online documentation has been updated and pops up a suggestion to the user to "Want to update offline documentation", i.e. the online help always has a offline copy by default. Bernd On 9/22/2018 9:48 AM, Antonio wrote: +1 to online help. On 22/09/18 16:16, Tim Boudreau wrote: I've been thinking for at least a decade and a half that javahelp needs to die. It's basically a clone of the Windows 3.1 help system. Evidence was, last I knew, that it was rarely used by real users. Online help would, IMHO, be fine in this era. -Tim - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists .
Re: My Personal UI Rant, Was: Think Java, not Electron! was: Apache HTML/Java UI instead of
Scott, you are writing what my heart also was telling me. Still, it never occurred to me to look at anything which had he letters "HTML" in their api's as I always link this to "web" and my app is super heavy non-web-desktop-app-monster-size-local-file-reading-not-usually-associated-to-browser thingy. Though the "What is the HTML/Java project goal? To be a portable abstraction over such pipeline!" is exciting and I now know that this is/could be the way forward. Thank for the good discussion - lots of the comments were an eye-opener to me as I live in my little desktop Swing/AWT/JavaFX world. Bernd On 3/13/2018 10:06 AM, Scott Palmer wrote: Sometimes I think the world has gone crazy. Here are a few simple observations: - JavaFX is the best UI tech that Java has going for it these days. - Swing/AWT has been heading towards obsolescence for several years now. It works, but the future of desktop UI with Java is JavaFX. - HTML is a HORRIBLE way to render an application. It works very poorly, if at all, and not consistently across browsers. (Look what people have to go through to try to get something as simple as a table with scrolling data and static column headers, for example.) - Javascript is junk. The interesting thing about stuff like Electron is that they managed to get it to work at all. We give it extra credit simply because it was done with technologies that make it so much harder to do. (It also tends to be slow IMO.) That’s cute and all, but ultimately wasted time. It would be that much better and cheaper to develop if done with better tech like Java/JavaFX. - The popularity of Web UIs has done a disservice to the development community. They have lowered the bar so far that we accept the utter rubbish and awful user experience of most web apps as ‘normal’. We have a generation of developers that don’t even understand why Javascript is garbage or how crippled applications are that run in a browser. Have you noticed when you see an interesting web app that you are more impressed because it is a web app? If it were a desktop app you wouldn’t give it a second thought. - I don’t know why anyone would want to bring HTML UI into a Java application (when they don’t have to) as it is such a massive step backwards. So stopping running around like the sky is falling. Swing/AWT, JavaFX aren’t going to disappear. Oracle wasn’t doing anything significant with Swing. If they stop, we aren’t likely to notice. JavaFX is the greater concern, because it is the better tech and still needs feature development. The community around it can keep it going as long as there is a consistent vision for it Ideas of using HTML for UI on a desktop app programmed in Java are ridiculously insane. We already have a much better cross-platform UI technology, no need to put work in to move backwards to an inferior UI tech. Scott - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists .
Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK
Indeed, lets look forward, I have not looked at JavaScript as always being into heavy desktop Swing apps. Over the years it has helped me with a demo app showing all kind of features a given system allows me to use. Like a toolbox, which I run and say - hey that's the component I need. Is there something like this for the HTML+JAVA api ? Or some websites showing the current func? Jaroslav, thanks for also looking forward and suggesting a way out of this swamp ... I will start looking into this. Bernd On 3/12/2018 10:59 AM, Jaroslav Tulach wrote: "Oracle has begun conversations with interested parties in the Java ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above referenced timeframes." The official announcement is here and people are finally starting to realize the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor development of anything new for these technologies. Even if they get transfered to their new owners, they will be in maintenance mode: Bugfixes and little features. No bigger changes - no new rendering pipelines using new nifty features of graphics cards. Just sustaining. I've been explaining this would happen since 2012. To help us out of this situation and save Java as a programming language I dedicated my days to smoothing out interoperability between Java and JavaScript with the goal to reuse the most flexible and portable rendering system of these days: the browser. My work has already been donated to Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's use it to build new features of NetBeans and other future Java desktop applications. Get started by reading Javadoc at http://bits.netbeans.org/html+java/ Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care about Java, then your future should be Apache HTML/Java API! -jt
Re: New NetBeans splash screen? :-)
Could be cool with a non rectangular splash. A trick - or rather hack ;-) to render such a splash without too much brain activity needed and leverage existing codebase, is to dynamically screendump the rectangular area were the splash would usually, and draw/copy in the non rectangular feature on top of that small screendump, then use the usual code to view the now rectangular splash which will look to the user as a non-rectangular splash (as long as he or she has not moved the window or got some popups in that second the whole thing takes). Maybe there is an easier way to make a non-rectangular splash ? (FX ? but that will include need of much bigger code change) This would allow to splash the logo only with some number inside referring to the release version. I know wild idea, but would look "different". On 3/8/2018 1:48 PM, Javier Ortiz wrote: Yeah, the current one for sure doesn't go along the new logo. Is branding part of this first release? On Thu, Mar 8, 2018 at 1:13 PM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: Hi all! Now that we have a new logo and new website — a next logical step would include a new splash screen. I.e., parallel to the NetCAT program getting started and moving along well, we could propose various splash screen designs, featuring our new logo and maybe some of the styles and colors from the website, followed by a vote thread? Just an idea, Gj
Re: [VOTE] Apache NetBeans Logo (NETBEANS-145)
Logo ID 2
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Just my 5 cents: We cannot afford to split the community. All users/developers should be using netbeans.apache.org as primary point of entry. As now, there should be an area for IDE and one for the Platform. Having both will allow users to possible explore new things they else never would see. On 5/2/2017 7:58 AM, Geertjan Wielenga wrote: will netbeans.apache.org be for Apache NetBeans developers only or also for Apache NetBeans users,
Editing permissions for Wiki
Please enable editing permissions for Wiki: Bernd Ruehlicke (bruehlicke) Uploaded picture to Confluence on my user. I am happy to see the positive atmosphere around this transition. I am for sure very excited. Bernd
