Great thing to bring this up! <cut> > Implement the free transform tool > > For exact specifications, see: > http://gui.gimp.org/index.php/Transformation_tool_specification Oh yeah, thumbs up for that! :) <cut> > Replace the GimpSizeEntry widget > > Right now both the code and the UI is a mess. The unit should for > example be in the text entry itself instead of in a combo box How about a new type of widget âSizeAreaâ or somethin' that would remeber value along with entered measurement unit? I know this is a long shot and thing more feasible in vector editing app but still I've been in a couple of situations when I'd love to have such thing. Currently all I can have is widgets that get value and mercilessly convert it to default units no matter what. I think it would be cute if such widget could hold equation leading to some answer e.g. â2 * .25 in + 6 inâ. It would display then â6.5 inâ but it would allow to correct equation if clicked upon. â.25â could be for example bleeds. <cut> > Slicing tool > > One of the most requested features by web designers and/or interface > designers, is the addition of a slice tool. Currently slicing images > inside GIMP can only be done in grids (using guides and the guillotine > action) and you can't split just one rectangle in the middle. > > For example, the following slice can not be achieved: > > ----------------------------------- > | | | > | | | > | |--------------------| > | | | > -------------| | > | | | > ----------------------------------- Am I the only one who feels that current notion of slices is wellâ a bit retarded? I'm often in a position when I've got to make slices that are overlapping or take only some selected layers into account when producing output images. In such cases slices like shown and widely implemented are nothing short of being useless. Agreed: the slices type presented make producing âWYSIWYGâ sites easy but I don't think they're much use for HTML writers. So, long story short I propose making slices that could look something like that: ------------------------------------- | --------------- ---- | | | | | | | | | | ---- | | --------------- | | | | | ------------------------------------- The biggest would be e.g. background, next (in the terms of size) would be menu and the smallest would be some icon. <cut> And let me throw in another thing. It's been in my head for some time but now I think it's good to show it to the world. Just in the matter of shear curiosity: I'd like to see some conceptual work/code/working example/whatever about automatically configurable grid processing. It may be more of GEGL project than GIMP one, but I believe still beneficial in the end. Since 3D rendering engines do that, maybe it would work nice in 2D world too. Of course a metric and some kind of benchmark would be needed to decide if sending some part of work over network to another node is beneficial. Anyway I think it have chances to make things snappy even on slow machines. I see it as a something between freakin' fat workstations, thin clients with some heavy âmother gooseâ and mighty cluster. It would (hopefully ;)) help to use what is at hand more optimally. Best regards! thebodzio
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
