Related
We are using install4j for to build our installer. We are facing bigger font size issue on linux RHEL 6.4.
On Linux RHEL 64, installer showing bigger font then windows which in turns to UI issue (i.e. form controls not aligned to each other etc). Is there any option in install4j that on linux we can have same look and feel or is there any property which install4j provide and can be set to avoid bigger font size issue on linux RHEL 6.4.
Thanks,
Jignesh
Different systems include different fonts by defaults. Those fonts do not have necessarily the same metrics (letter size). Linux systems often default to Dejavu which is slightly larger than Arial (usual windows default). And btw OS editors are constrained by font licensing agreements and even when they do bundle the same fonts they don't bundle the same versions nor use the same font rendering engines so that's unlikely to change in the future.
The moral being, don't use designs that rely on constant letter sizes for cross-platform apps. They will fail horribly sooner rather than later. (even ignoring new tech like hidpi). If your widgets do not adapt to text size, with proper grid fitting, you lose.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I started coding around 5 years ago. I was introduced through Java and Eclipse which both have substantial stigma attached in the programming community. A number of people at the company I currently intern at prefer emacs or vim. I can't see how a basic text editor is faster or easier than an IDE in general although I appreciate some things like building tend to be faster from the command line.
Is this a case of the 'old-boys' club or can it be more efficient to program a project in this way?
Can you provide some use cases to demonstrate? If I were advocating Eclipse I'd say refactoring and auto-completion were pretty handy tools.
Gav
Vim / Emacs
Very fast/efficient code writing
Low memory footprint
Quick access to command line
Infinite possibilities through scripting/plugins
Never have to leave the keyboard
Eclipse
Full-featured IDE for many languages
Great refactoring support
All of them
Cross-platform
Feature rich
Extensible through plugins
I typically find myself writing volumes of code through vim and performing debugging tasks through my IDE. Familiarity with the code base is certainly a factor, as an IDE is a great tool for jumping around and learning unfamiliar source code.
I got started in IDEs like Eclipse, but switched to Vim about 2 years ago.
Reasons you may want to use a text-mode editor:
It can be used as an IDE for just about any language (you learn it once and use it for everything)
It can do all those fancy things like auto-completion, refactoring and many more complex operations, which you can extend by adding macros or plug-ins
It works just about everywhere (and can be used through an SSH shell)
You don't need a GB of ram to run it
If you really persevere, you will find that working in an editor like this will eventually be faster, and in fact becomes ingrained as a sort of 'muscle memory'. This means you can code without slowing down to think about the process.
The argument "Eclipse for Java" is a different argument than "Eclipse for [something that isn't java]". Eclipse does rock for Java.
I mean, vi is like a screwdriver, or maybe a swiss army knife, and Eclipse is like a big CNC combo mill and asphalt spreader. You don't exactly compare them, you kind of just use both.
Also, are you working inside something giant, which you know little about, but which Eclipse understands? An example would be working on Eclipse itself. Here, Eclipse has perfect visibility, total language support, and you need the toast prompts and the documentation links.
But if you are typing in a 100-line Ruby program to convert an SQL database, Eclipse doesn't add much value, especially considering its baggage.
It's also critical to set up vi right, or you won't grok the appeal. Autoindent, showmatch, tab handling, and various other options should be set. You should have a easy way to generate a tags file. Google can find tag generators, or just write one from scratch, with a few lines of shellcode and sed(1).
I don't consider refactoring to be a criteria. That's not something you do once an hour or even once a day. Sure, fire up the big IDE when you need to refactor. Oh, and don't expect automated refactoring of anything except Java.
Finally, vi can actually do a lot of things that the IDE can't begin to do. The grouped regular expression global substitution is kind of a generalized refactor-anything engine. To appreciate the vi gestalt you need to learn the line (":") mode. Briefly, it's like having sed(1) inside your editor.
It all depends on what you want/expect and what your usage model is.
If you're looking for a Java IDE, Eclipse is difficult to beat. It's written in Java, for Java, by Java folks.
If you're looking for a tool to edit files from the command line quickly, Emacs or vi both fit the bill.
If you're looking for a tool from which you never have to leave because it can do anything you want (send/read mail, manage projects, todo lists, compile, debug, etc. etc. etc.), then Emacs is more "efficient".
If you're looking for reasons to switch editors, figure out what you want. If you want a better Eclipse, vi and Emacs won't give you that, stick to Eclipse.
If you're looking for a small, nimble editor, vi will fit the bill.
If you're looking for the ultimately extensible editor, Emacs is the way.
Whichever tool you decide to go with, immerse yourself. Learn all of the ins and outs, extend it to meet your needs. Use it to its limits and become efficient in its use.
Emacs can be a powerful IDE, but having gone from Emacs to Eclipse, I have to say I would never go back. Eclipse just offers so many features that you can't get within Emacs.
Mylyn and scoped views of the data and files I'm using, the debugging UI, CVS UI, are all built in and easy to get and use. I'll use the mouse a little to get'em.
First things first. VIM is more productive for programming than Eclipse. Your personal productity in VIM may be abysmal, but the potential cap of VIM is much higher. This is a fact.
VIM is a martial art. It feels unnatural when you first use it. And you can't even make it work. It takes years of practice to gradually become productive. You focus on mastering a little detail at first. Slowly all these bits you master add up until text is flowing effortlessly out of your finger tips onto the screen. Complicated edits that would make your co-worker sigh will jump from your hands before he can finish his exhale. There are few people who can use VIM. Fewer who can use it productivley. And you may never meet a master in your life time. But they are rumored to exist.
VIM is designed to keeep your hands on home-row. Moving your hand from the keyboard to the mouse is demoralizing. It's a gross motor movement. Moving your arm has a phsycological effect that hurts your motivation. Using VIM, someone could bolt your wrists onto the keyboard and you could still easily open up files, split windows, open tabs, build the project, search/replace, change fonts, change colors, etc. And all at lightning speed.
VIM is modal. That means you don't have to do complex key combinations where you hold down control+shift+Key. This hurts your hands in the long run. Instead you execute commands. There is no need for key combos to due to the modal nature.
We store data in our memory like computers do. Our memory can only hold a few values at a time. See how many distinct integers you can hold in your head before they start to slip away. We overcome this human limitation by writing stuff down. If data falls out of our memory we can easily look at what we wrote down to get it back. If your time is spent doing gross motor, physical things you are losing time that could have been spent on processing data in your brain. You want your mind to flow onto the screen without any effort at all. It may not sound like much but VIM's ability to effortlessly transfer what is in your mind to the screen is a BIG productivity boost. It's hard to put in words what I'm trying to say.
VIM supports code completion. Both textual and look-up based. It can pull text from mulitple files. Anything you desire can be had in VIM. Either make it yourself or use something someone else cooked up.
VIM supports goign to definitions with ctags. You can also find all references of an item. Again, anything you desire can be had in VIM.
The scripting of VIM is huge. You can download or create thousands of color schemes and change colors in an instant. Try to change fonts or colors in Microsoft Visual Studio and it will hang for 20 seconds while it loads data. It won't let you store color schemes and you must spend 30 minutes tweaking your colors and fonts every time you want a change of scenery. In VIM you can set line spacing to zero to fit more lines of code on the screen. I get over 80 lines. Visual studio uses 2 pixels of spacing for every line and you can't adjust it!!! Less lines = more scrolling = less productivity = forced to use small fonts for more lines = eye strain.
Split windows are opened in an instnat in VIM. It's usefull when you need to look at data in one section of the code that's far from the place you are typing (or in a different file). You don't have to spend time resizing windows, or worry about GUI windows overlapping each other and falling behind each other. Un-related code windows can be opened in tabs as to not take up screen space, but allow quick switching.
VIM as an IDE: http://www.youtube.com/watch?v=MQy2rVOf-z0&feature=fvwrel
VIM the revenge: http://www.youtube.com/watch?v=lQNFfhC4QI8
I've used vi for years to edit code in a variety of languages, and really love it. But I've found IDEs like Eclipse to be even nicer for Java development, and now I tend to work in Eclipse almost entirely. I drop out to use vi from time to time for a few specialized activities like bulk-inserting copyright notices, mainly those dealing with certain kinds of rote edits that aren't well automated in Eclipse. I also have my Windows .java file type mapped to vi for when I just want to look at a source file without waiting for Eclipse to open up.
Some of the attractive features in Eclipse are:
method name completion
error highlighting
pop-up javadoc comments
refactoring
I do find it a lot more efficient than vi in general, so you should try it out and see if it that holds true for you too.
I remember reading somewhere about a study which showed that people perceived keyboard shortcuts as more efficient than mousing, when in fact it wasn't always.
Another psychological effect is that we attach value to things which are expensive, i.e. since Emacs is harder to learn it must be better in some way.
I think those effects could explain a lot of the extreme affection some people have for Emacs/Vi.
However, in the case of Eclipse, I find it can be very slow and even crash occasionally, but that is not a case against IDEs in general.
I use both Eclipse, VS and Emacs regularly. I would use TextMate too, but I don't have a mac anymore. It depends on what I am doing, more specifically, what system best supports my language and tools.
I know people who spend considerably more time programming their editor, than they spend doing something useful. Some of them even admit themselves that they only do it for the challenge. Other people often claim that Emacs/Vi can do much more than IDEs, because they are scriptable. Well, most IDEs (including Eclipse) can also be scripted. In that sense almost all editors are equivalent (though, I admit, some editors are more easily scripted than others).
If you like IDEs, my advice is to keep using one. There is no One True Editor.
EDIT:
This seems to be the article Nick Bastin is referring to. I agree that it is far from a definitive source. However, I still think my point about perceived and real productivity not being the same thing still holds.
It depends on the languages.
For Java or .NET use an IDE (Eclipse,Netbeans,Visual Studio...).
For almost all the other languages(C,C++,ruby,python,haskell,lisp...) vi and emacs are better in my opinion.
The efficiency provided from vim/emacs is mostly afforded by their heavy keyboard use. In these programs you can do most anything directly from the keyboard, rather than having to stop and use the mouse.
I would anytime go for emacs rather than eclipse. I also have to say that bare bone emacs, is not that great, but after some tweaking, you will never want to let it go. In particular I will tell you how helpful emacs was while writing my Master's thesis, that should make clear why Eclipse is inferior, just because it is less versatile.
I my master thesis I wrote in the following programming languages: C++, Python and R. Complementary, I had to write the thesis, for which I used LaTeX. Moreover, I had to write a bunch of shell scripts and cmake scripts. Guess what? Emacs has great support for all of it. Specially, it was a pleasure to work with AuCTeX to produce LaTeX documents. Then, Emacs provides the great ESS mode for working with R. Likewise, it provides facilities for python. Once I had my cmake scripts for building the C++ code, I only had to call compile from withing emacs and I was done. Eclipse cannot do this things altogether, therefore you will need to learn to use many different programs. Note taking? There is org-mode for that, and it is great!
And then, my program needed of a very powerful computer (not like any laptop). So, I could just do everything remotely from within emacs!!!! Using tramp, I found myself doing remote interactive evaluation of R code, remote compiling, executing and debuging C++ code, and everything within the same good local emacs window I had been using. In contrast, my friends who used a separate tool for everything were much slower in developing software that was meant to run in another computer.
Like this I have some other stories, but I think, this will give you a good idea on the things you can do with Emacs. All in all , I think choosing to use emacs (despite the learning curve) has been the most productive decision I have ever made.
Hope it helps.
I'd say the actual vim/emacs editors are far superior to the Eclipse text editor in terms of the shortcuts they offer. However, I completely agree with you about refactoring.
Most people have to write scripts to do the sort of level of refactoring Eclipse is capable of. I think part of it is bragging rights or people just doing it the same way they always have.
We've had this argument at work recently. My take was that one single feature I couldn't do without is Emacs's autocomplete. Eclipse's autocomplete is based on syntactical analysis - the code gets parsed, and as you type code you're offered choice of completion. Emacs' autocomplete is base on simple textual analysis. That means it works in plain text, in comments, in documentation - everywhere. I keep saying the Emacs' autocomplete is what IntelliSense wants to be when it grows up.
Update:
Eclipse does offer Alt-/ which is supposed to be similar to Emacs. Not sure how well it works, though.
The only place I prefer an IDE is for debugging. I set up my vim environment for debugging but is was so painful to use, so clunky, that I now just switch to my IDE (Netbeans) when I need to debug. vim is great for text editing, the IDE is great for more complex stuff (like debugging, and some project management related tasks).
Like some of the posts above, I started out with an IDE (Eclipse). From there I moved to Emacs, and then I moved back to a rich text-editor (TextMate).
For me, the efficiency was the ability to have an editor at the interface level. Allowing me to integrate other service I've built up (or others) into my pseudo-IDE environment.
I am relatively new in a software development. I have noticed that in some cases a text editor with extended text processing capabilities (I use Notepad++) gives me a better productivity than an IDE (I use the Eclipse and the Netbeans). In the era of IDEs, does it makes sense to learn emacs (or some other tool that you suggest?)
Yes, and no.
Yes for the exact same reason why a doctor should be able to get an approximate diagnose from your symptoms by using his experience, and not putting the list of symptoms in a google query and find the answer.
Yes for the exact same reason why airliner pilots are taught to fly without fly-by-wire even if all airplanes are today fly-by-wire, so almost everybody is able to keep them flying.
No, because if you need specific tools to make your life easier, such as GUI designers, Intellisense, access to documentation, then clearly Emacs is not enough.
Still, I remember that many developers at Microsoft organized a fund raising for uganda vim children.
Summing up, you need to use what makes you more productive. In many cases, emacs (or vim) is more productive than a huge IDE that makes coffee.
Even if you were using an IDE, it's still useful to know Emacs/VIM. You don't have your IDE around all the time, and while doing something via SSH, you don't really have any other option (yeah you can use nano, but thats not very effective).
When you do software development, you often deal with a lot of text besides code. I may use an IDE for most of my coding, but often I'll use Vim for plain ol' text viewing and manipulation.
Sometimes I need to view code, SQL scripts, XML, CSV, or TXT files. Other times I may want to perform bulk replacements on those files, or extract out certain chunks of text from it.
IDEs are good for writing and refactoring code, but aren't meant to be used for generic text viewing and manipulation. For that, I'd recommend having the full power of something like Emacs or Vim. Notepad++ can be good too.
In short, use the right tool for the job.
Everyone here seems to think that Emacs/Vim are light-weight compared to IDE's. This couldn't be further from the truth. Even the best IDE's do not have the features that Emacs does. In what IDE's can you program completely without moving your hands from the keyboard, read your email, chat with Jabber, run an integrated debugger, view your calendar, program your own functions, and send dbus commands? That's only the surface of what Emacs allows; I'm sure Vim has similar capabilities.
Ignoring productivity completely; remember why you started programming in the first place. You like to create stuff, you like to know how stuff works, you like creating clever solutions to obscure problems, you like tinkering, you like learning new things, you like creating tools that help you do things.
With this in mind the answer is yes, learn it if you think it will add to the delight to your days. Maybe you will also get some work done along the way. Fiddling with eamcs will not make you melt. You might even make a life-long friend of it. Happy Hacking.
Emacs is an IDE. In fact, you could argue it's a whole operating system.
vi, on the other hand, is an editor.
Yes, it makes sense to learn vi, since it's about the only editor you can use on anything vaguely posix, even if the GUI isn't running or the network is incredibly slow (vi is usable at 300 baud). Basically, it's the unix administrator's safety net of an editor. I've used it to rescue myself from broken device drivers on an OS X server that would only come up so far as single user, so even the must GUIfied Unix out there can still be saved by humble vi.
It makes some sense to learn emacs too, but perhaps not quite so much these days.
I would say it helps to learn emacs (or say vim).
Personally I'm comfortable using IDE (eclipse) for Java developement, when I code in perl or python I prefer to use emacs. Also if you are in a resource constriant environment (say) starting an IDE like Eclipse (which would crawl if there is anything less than 1GB RAM) to write a perl script might not be feasible. In such cases a vim would be neat tool of choice.
I have an application that is built to work on Windows, Linux, and Solaris that uses the Perl/TK GUI. Due to constraints, we are limited to Perl/TK only. Moreover, we are limited to an old Perl/Tk version, 5.00404.
I'd like to work within these limitations to make the GUI look as nice and modern as possible.
Are there any web-resources that have TK design schemes (for buttons, frames, colors, etc) that could assist me in this endeavor?
I am also looking for modernization advices like the one that I found here:
If you're finding that your Tk apps look a little ugly on X-based systems, try adding the following lines to the top of your script:
$mw->optionAdd("*font", "-*-arial-normal-r-*-*-*-120-*-*-*-*-*-*");
$mw->optionAdd("*borderWidth", 1);
Try using images instead of button elements, then you can have whatever style you like and the fonts can be baked in. This will work for pretty much any element where the contents are not dynamic - including backgrounds on panes and such. Granted it's more work but it does solve your problem, especially if you have a competent artist in your project group.
You could use the Tk theme engine to give your app better looks.
Using optionAdd to tweak defaults through the option database
is a reasonable start. A thread about this can be found at:
http://tcl.projectforum.com/tk/221
Download griffin.kit from there, use the sdx tool to unwrap it and locate
griffin.tcl to get a good set of option settings.
http://wiki.tcl.tk/3411 for the sdx tool.
Since in Linux the background of Tk::Entry and Tk::Text is grey i would also use the following two lines.
$mw->optionAdd( '*Entry.background', 'snow1' );
$mw->optionAdd( '*Text.background', 'snow1' );
Replace 'snow1' with a color of your choice. You can also use the hex representation(RGB) of the colors like '#ff9696'.
The Tile themeable engine for Tk makes it look much prettier. However, Perl/Tk has lagged far behind Tk's development, and can't take advantage of Tile and other advancements.
You should investigate whether Tkx is an option for you. It's not completely compatible with Perl/Tk, but the API is pretty close. It's a bridge between Perl and Tcl/Tk, so it can use all of the modern Tcl/Tk features (like Tile) while still having application logic coded in Perl. Quite a few of ActiveState's own graphical utilities use Tkx, with fairly good-looking results.
(source: activestate.com)
Perl 5.00404 is incredibly ancient, though. The Tkx dist claims to depend on Perl≥5.008... I don't have an old enough Perl to see how accurate that is.
I'm trying to implement a version control system, but as most of us know designers don't feel comfortable with version control systems. I'm looking for a solution mostly for our designers using Photoshop, Flash and other design tools.
It's not a big deal to use a version control system, like VSS 2005, with our frontend and backend coders, but we have some serious problems with our designers. They mostly refuse to use version control systems, and they are right at some points, mostly on productivity level. They mostly work on more than one file, and on more than one application like Photoshop and Flash.
I don't know if version controlling is the right answer or not. Maybe we have to implement a backup system, but there has to be a versioning system, I think. I and our designers are very tired of doing the same thing or going back to the previous designs over and over again.
It would be wonderful to know how digital agencies overcome this problem. If version controlling is the answer, please share your tips on how to make designers comfortable with version controlling.
EDIT 1: Maybe it would be great to have a solution like Dropbox, as it doesn't disturb you with check-ins/check-outs. All you have to do is to open up a file, work on it and save it, the rest is handled by Dropbox.
EDIT 2: We are on Windows, so no chance to implement anything other than Windows support :(
Thanks...
I haven't actually ever done this with graphic designers, but is it possible that Subversion's WebDAV support might work for them? You can mount a WebDAV share as a drive under Mac OS X and Windows XP & Vista, I believe. Each save becomes a new revision in the repository.
And as for your second, hidden question: Yes, you do need to implement a backup system. At least if you value your data.
Adobe has it's own version control, Version Cue, which is bundled with the Creative Suite package. http://www.adobe.com/products/creativesuite/versioncue/sdk_overview/ Apparently, Eclipse can plug into this. I haven't tried it extensively, but I know it integrates nicely into the file dialog in Creative Suite.
NOTE: Version Cue has been discontinued by adobe after the release of CS5:
http://www.adobe.com/products/adobedrive/
Adobe Version Cue maybe?
You might want to try subversion because there are plugins for windows explorer and max OS X finder. integration with the filesystem has been a big help for me on projects where non-developers had to work with source control. This includes projects that have had designers.
Another key thing that helped was having a good directory structure for the files the designers and other non-developers worked with.
I just came accross ConceptShare and it's pretty great...it's not automated version control but you could use it for that and it's a great way to collect and document feedback.
You can try Subversion (installed on a local or remote server) plus Adobe Creative Suite plug-in that would face the designers - Pixelnovel Timeline
It's compact, has previews of all versions (submitted via the plug-in), works for Photoshop, Illustrator & InDesign.
If developers also use Subversion, everything (code & design) can be kept in one place.
Instead of trying to integrate a version control system with lots of applications on different operating systems, you might want to have a look at copy-on-write file systems such as http://en.wikipedia.org/wiki/Ext3cow. That way your designers won't even notice a difference; all they will have to do is save their work to a network share on a linux/samba server using ext3cow.
I'm both a designer and coder. I usually version control code (text data) with git, and simply use "save as" with a version name for graphics (binary data). And I run Apple's Time Machine on top of all that, for safety.
To me, version control on graphic files would just be a burden. I'd have to roll back to see changes, and you wouldn't even get one of the great features of version control: see the changes you did in a specific commit just by looking at diffs. The log feature is nice though, to see how you progressed in time, and notes, but to me personally it's not worth it.
Take a look at Perforce - it has a plugin and tools that allow you to use it from within designer tools such as Photoshop, its also super fast and integrates well with Visual Studio - runs on Windows as well as Linux
What I did once was create a "Snapshot" shortcut on the desktop that added and committed everything from a specific directory.
If every designer commits to their own branch (trivial with a DVCS but easy with SVN too) there will be no conflicts, and the cross-branch merging can be done at intervals by someone who isn't afraid of it.
I've been having my eyes on GridIron's Flow for a while now. It looks like a competent version control suite that has some neat asset management features such as visualization on graphics between versions and relationships between different assets. Flow has support for handling files for adobe photoshop, illustrator, flash etc. However as of now (early january) GridIron hasn't released Flow yet other than having to announce the beta program.
Most digital agencies that I know of that mainly do web development use Subversion for version control. To avoid conflicts on image files an artist will lock the files he or she will work on. That way, another artist won't do the mistake of overwriting changes. This requires some coordination among artists and devs so that noone steps on anyone shoes. Also, if someone forgets to unlock, there is the possibility to break locks.
If you're into distributed version control you might want to take a look at Mercurial as it has good support for Windows and has some neat cheat sheets. The Ruby kids are using git but is rather lacking in Windows.
Before using version control with artists, at least make sure they know the basics of version control and let them fool around with it in a sandbox. Also make sure they've set up some basic rules of conduct when collaborating with each other and interacting through version control (i.e. ways to make sure they don't destroy each others works or step on each others toes).