My News: TOP - Autos Intimate goods Chairs Underwear Ladies handbag Bracelets Sportswear Top auto-moto furniture Dating Boots FDA Approved Pharmacy Boats Necklace Yachts Medical tests Suits Medicine news Building materials Top casino Rington Tunings Sale Auto Chronometer Blog Search the Web Cases Mobiles Cigarettes Cars auto-moto Ear rings Cigarette Green Card Information

    Follow me

     Open Source and Diligence
    Filed under: — David @ 2:10 pm

    XVG was my first new open source project in a few years, and I’ve taken a somewhat different approach with it than I did with the others (at least at first). I’m going by two basic rules: work on one thing at a time, and keep the repository in a state where someone can build the application and run it at any time. Unit tests definitely help with that second one. I’m also trying to be responsible about maintaining XVG as an open source project. I try to keep in mind that it is basically on display to the whole world (even if, in practice, not many people are looking at it right now), so I should think of it as a front lawn instead of as a closet.

    ACCELA wasn’t as easy to work on under those rules, since for the most part it’s a collection of mostly independent parts. There may still be a few things that are not well tested; I never wrote a test/demo app to test everything. I mainly left that for features that were more my own code than just simple wrappers: the auto toolbar and the document classes.

    Volley, on the other hand, definitely would benefit from those practices, but when I started it I didn’t quite have the habits of focused development that I’m trying to adhere to now. For example, a while back I made a fairly major change - switching over to the boost classes for threads - but I have yet to check that in because I started working on other things at the same time, and I never quite got everything fully working. I didn’t really get into the concept of unit tests until Xcode 2 made it convenient. One of these days I need to get back and finalize these changes; perhaps I should plan to do that after the first release of XVG.

    There is always the temptation to decide I’m bored of working on a feature, and skip over to something else instead. But then I end up with a mess of half-completed features. I caught myself going down that road just recently with XVG. I had started to implement drawing and editing tools, and I had a chain of logic that led me to start implementing the Bring to Front/Send to Back commands.

    You see, to be able to switch tools, I needed to have the tool palette item in the toolbar (since I plan to do that instead of a floating tool palette). But I wanted the window to look good, so there should be some other toolbar items too. The item ordering commands seemed like good candidates, so I started working on those. But once I had the code written for them, I remembered that I still hadn’t tackled the issue of Undo, which I would need not only for these new commands, but also for the recently-started editing tools, not to mention the inspector palette that’s been there for a while. So really Undo needed to be the next task; putting it off would only mean more work when the time came to adding it in to already-written commands.

    That’s why, if you were to look at the XVGView.m source file right now, you’d see all the written-but-untested item ordering commands commented out. For the sake of keeping things clean, I don’t want to leave anything in that hasn’t been reasonably tested, and it simply wasn’t the time to test those commands.

    These principles of unit tests and focused development appeal to me a lot, and I often think there are some good life lessons that can be extracted from them. These practices do not happen in isolation; when you develop good habits in one area of your life, it’s going to help you in others too. And of course, the same goes for bad habits.

    Focus is a good thing. It helps fight laziness, and it gives you a way to express that you care about what you’re doing. If your work on a project consists of randomly poking at various individual tasks, then you won’t get much satisfaction or progress. If you don’t actively demonstrate that you care about the project, you will come to care about it less. It will mean less to you because you haven’t given it meaning.

    Unit tests are a way of defining the goals and standards for a program. They give you a way to tell the computer what you expect out of the program, so that the computer can tell you if it lives up to those expectations. I only wish there were such a quick and easy way to run unit tests on my life, giving me a report of any ways in which I am not meeting my own goals and standards. Instead, I have to do it the old-fashioned way, through introspection and developing the good habits that defend me against the bad ones.

     Implementation questions
    Filed under: — David @ 8:33 am

    XVG development has slowed down a bit as I face the design challenges involved in doing drawing tools and object manipulation.

    • What should selection handles and path control points look like, and how will they be differentiated?
    • Which object should draw them? The view, the tool, or the selected object itself?
    • How will multiple selections be handled? I’m leaning toward the OmniGraffle method of drawing one set of selection handles as if the selected objects were in a group.
    • What determines the properties of a new graphic object? If it’s based on the previous selection, what happens if it was a multiple selection with mixed properties? Maybe that question itself is enough to rule out the previous selection idea.
    • What should the tool cursors and icons look like? For path editing, I’m probably going to do something like Photoshop’s white-centered arrow. I think the outlined appearance matches well the idea of editing paths. I’ve made my own version based on the system arrow (complete with shadow), where the white center is semi-transparent.

    It also occurred to me yesterday that maybe Core Data would be an appropriate solution for the XVG internals. But I’m not sure I’m familiar enough with it to decide that for certain. I played around with constructing a data model document in Xcode’s visual editor, but it got somewhat complex because of the many different kinds of SVG object properties. Fill color, for example, can be a literal color, or it can be a reference to a gradient. I’m not sure if that maps well into the Core Data system. Also, the only attribute types that seem to be available are numbers, strings, and binary data - no structures, such as points and rectangles. That seems awkward to work with in a graphics application.

    Edit: After actually reading that Core Data page, I see that they even mention a “vector-art illustration program” as the kind of application in which Core Data can be used. So I’m giving it another look. Anyway, it turned out that my first stab at creating an XVG Core Data data model wasn’t the best way to go. I created it from scratch, but you can have Xcode create one automatically from your existing classes… though for some reason it ignores parent classes.

     MySQL resurrected
    Filed under: — David @ 5:07 pm

    I finally fixed my MySQL problem that started in February. The problem was the location of the mysql.sock file, which client apps like MediaWiki use to connect to the database. I have no idea how they got out of sync, but MySQL was putting it in /tmp, but other apps were looking in /var/mysql.

    I thought it would be easier to change where MediaWiki was looking, but that setting didn’t seem to be in the settings file. Maybe it happens at the level of the PHP MySQL interface. That’s really getting into the land of the unknown for me, so I tried the MySQL angle.

    A Google search turned up an informative MySQL documentation page. I ended up creating a file at /usr/local/mysql/data/my.cnf, which didn’t exist but it was where MySQL was already looking for extra settings. The file looks like this:



    After restarting, and deleting the old .pid file in /usr/local/mysql/data, it was finally working again. Why that file didn’t get deleted during the restart, I don’t know.

    I’m happy to have it working again. I’m using MediaWiki as a personal journal on my PowerBook, so finally being able to access all the old entries again is really nice.

     Centering in a scroll view
    Filed under: — David @ 10:42 pm

    NSScrollView does strange things when its document view is too small, especially if it isn’t flipped - it’s pinned to the bottom left corner. What I want is for it to be centered, like Photoshop (or OmniGraffle, which even has a fancy shadow).

    I had found some code, by the name of SBCenteringClipView, which claimed to do what I wanted, but for whatever reason it didn’t work for me. When the window was bigger than the content, there was a hall-of-mirrors effect, and when it was smaller, the view would zoom off in one direction or another.

    So I tried out another strategy that I had been thinking of: put the document view inside another view, which resizes itself to either fit just inside the scroll view, or to the same size as the document view, whichever is bigger. When the scroll view is bigger, regular old autosizing keeps it centered. When the document view is bigger, then you get scrolling. I also had to override isFlipped to return YES so it would scroll down instead of up, which fortunately didn’t unflip the XVG view itself. And it works.

    I probably spent more time trying to get SBCenteringClipView to work than I did on my own solution.

     Documents and arrays
    Filed under: — David @ 6:51 pm

    For a while it’s been bothering me that the ACFArrayT template doesn’t work well with CFTypes; ACFArrayT<CFStringRef> yields the wrong type. What you really want is ACFArrayT<__CFString>, but __CFString is supposed to be an implementation detail that you shouldn’t have to deal with in your code. I had been dealing with this limitation in ADocument, and I decided to finally hammer out a cleaner solution. I looked at how boost’s remove_pointer works and put together my own version - without all the compiler workaround macros, since it’s only likely to be used with gcc. So now we have the ACFTypeArray template. I’d like to do the same with dictionaries, but that’s more complicated.

    I also finally automated ADocument’s Save As dialog, building the file types popup menu based on the document types in the application’s Info.plist file. I had already done this a while back for ADocumentManager’s Open dialog; I’m kind of surprised it didn’t occur to me then that I needed to do the same for the Save As dialog.

    With this change, ADocument’s type index variable also finally has a better reason to exist, which makes me feel better. Before, it was there basically just in case a subclass wanted to use it. In a way it has to be there, since the only way you can keep track of the popup menu selection is through the callback from Navigation Services, so you have to store the value. I was tempted to take that variable out, since its meaning depended entirely on how the subclass assembled the file type list, which suggests that it doesn’t really belong in the base class. But now, since ADocument itself creates the list, the type index really does have a home there now.

    I also deleted the CVSROOT directory that came over unnecessarily in the automatic CVS-to-Subversion translation. So everything’s a little cleaner all around.

     ACCELA moves to Subversion
    Filed under: — David @ 6:35 pm

    The ACCELA CVS-to-Subversion conversion happened faster than I expected - especially since SourceForge didn’t notify me when the process was completed. So in the mean time I had committed a few more changes to the CVS repository. Yesterday I moved those over to Subversion, and made it official by removing CVS from the project page menu. The repository’s still there, but the project site no longer has the page about how to access it. It is officially retired.

    Today I integrated some changes I had made at work, including some significant improvements to ADocumentManager for filtering files in the Open dialog. I ran into some issues with handling multiple document types, and this doesn’t come up in the test app because it just has plain text documents. I should probably add RTF, and write a unit test or two for the file type filtering. There was also an issue with ADocument not removing event handlers from its windows, which was causing a crash which also didn’t come up in the test app. I’m not sure why. But it’s fixed now.

    Filed under: — David @ 1:28 pm

    The round-trip integrity tests are in place, and they all pass. There was one thing I had to sort of punt on - some kind of precision issue with color values. Certain colors weren’t coming back in with exactly the same values. But since the variations only came after the sixth decimal place, I decided that was close enough. I’m not sure that would even translate to a different color on the screen. So I modified the test to allow differences of less that 0.000001. Close enough, right?

    There were other things I was tempted to punt on and leave some tests in a failing state. There was a path with an arc in it that wasn’t coming out the same, and my first inclination was to say “well, I haven’t implemented arcs yet, so that doesn’t matter.” But it turned out to be an actual parsing bug, which is independent of whether arcs are implemented or not.

    So I was able to get the whole round-trip test to a point where it has no failures, and that’s always a good feeling.

     SVG convenience vs UI design
    Filed under: — David @ 10:17 pm

    I finally committed the changes that accumulated over the weekend. Not that it was a busy weekend of coding, but I did get a little done. The main twist was that since I was going on a trip for the weekend, I copied all the XVG files from my desktop Mac to my PowerBook, and eventually discovered that for some reason committing changes from Xcode on the PowerBook doesn’t work (I get an incomplete error message). At first I thought it was because I copied the directory over instead of actually checking it out again, but when I tried doing the checkout method the error persisted. I think Xcode isn’t getting my name and password, though it works fine on the desktop Mac. But svnX lets me specify the name and password, and committing from there worked fine.

    The main changes were working around the unclosed path hit testing issue, and starting on XML generation. That wast mostly in place before, it just hadn’t been tested. My plan is to have a unit test that ensures round-trip integrity from XVG to XML and back, by testing that with each test suite file.

    I’m tempted to start on filters, partly because transfer modes (overlay, color burn, etc.) are available in Core Graphics, so that’s one thing I can do before I have to start learning Core Image for the fancier filters. But the structure of filters and primitives is more complex than the other stuff I’ve done so far, so that will take some planning just to get the basics in place. Not only do I need to plan out the rendering and the object hierarchy, but I need to figure out how the user interface is going to work. I want it to be easy to drop in basic effects, while also exposing the full power of SVG filters.

    The principle here is that for every SVG feature I support, there has to be a UI for it. Some features are convenient for SVG authoring, but from the UI standpoint of creating a drawing app, they don’t make sense.

    For example, I currently have support for the polygon and polyline objects, but really they’re so similar to paths that I plan to eventually change it so that those objects are converted to paths when they are read in, and the app will not have a polygon or polyline tool, just a path tool. There’s just no reason to have them when the path tool will have all the same features plus more. I’m thinking of doing the same with rectangles and lines too.

    Similarly, there are path convenience commands for horizontal and vertical lines, or curve segments with control points that mirror the previous segment. They let you have more compact path data, but I don’t think there’s any good reason to represent them in the interface. I just convert them to regular line and curve segments as I read them in. I might check for opportunities to use those commands in the SVG output, because it would make it a little more readable, but that’s not a really important feature.

    This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

    Powered by WordPress

    Shareware Icons Games
    Topic - News Blogs: Bracelets auto-moto Chairs Blog Search the Web Top auto-moto Boats Autos Cases Intimate goods Necklace Trousers Underwear Top casino Sale Auto Building materials Evening dress Yachts Tunings Medicine news furniture Rington Replica Rolex Mobiles Rolex Replica Boots Ear rings Fashions Green Card Information Balans Cigarettes Medical tests Sport Betting Cars