Ты уже подумал как твоя кнопка будет ловить события?

Да, будет обрабатываться событие движения курсора, если он над кнопкой(координаты кнопки известны), ставим флаг, и если кликнули мышкой, то генерируем событие и перерисовываем кнопку... Но меня сейчас больше интересует, почеу оно так рисует, такое ощущение, будто под кнопкой рисуется то ли тень, то ли она сама рисуется два раза... не понимаю :(

Кинь полный исходник - тогда скажу в чем точно проблема. Пока есть лишь догадки. Например, у GtkEntry есть курсор, который «мигает», а ты эту область пытаешься перерисовать.

Я как-то тоже бился с тем, чтобы в GtkEntry дополнительную информацию рисовать. Помню, что было много проблем. Рисовать поверх виджетов - всегда плохая идея, это нарушает инкапсуляцию виджета-предка.

В данном случае - чем тебя не устраивает gtk_entry_set_icon_* ?

Залил сорс сюда http://www.fayloobmennik.net/614796 По поводу курсора, я сдвигаю его(set_inner_border), правда с ним есть ещё одна «особенность», если его установить скажем в 30 пикселей от левого края и начать забивать в GtkEntry текст, то при достижения курсором конца поля(правого края), весь текст начнёт сдвигать влево, не смотря на этот inner_border, т.е если кнопку нарисовать вначале поля, то текст залезет по неё, в архиве есть собранный бинарник, можно увидеть этот эффект наглядно. Что касается иконок, то их можно разместить только две, слева и справа, хочется более универсальное рещение.

Попробовал просто нарисовать обычную линию, с помощью cairo, на расстоянии 1 пиксель от верхнего края, такая же фигня. Причём, ощущение будто линия «отзеркаливает» на верхнюю сторону виджета. Если нарисовать её на расстоянии 2-3 пикселя от верха, то всё нормально. Причём если рисовать ту-же самую линию снизу, или скажем возле правого края, то всё нормально, запарился уже :(

cairo_set_source_rgb(cr, 0.0,0.0,0.0);
	cairo_set_line_width(cr, 1);
	cairo_move_to(cr, 1,2.5);
	cairo_line_to(cr, 18,2.5);
	cairo_stroke(cr);
	cairo_destroy(cr);

Как-же правильно рисовать на виджете?

Вкратце, я бы убрал рамку у Entry (через стандартный метод), положил бы его внутрь себя и сам рисовал бы рамку со всякими др. своими элементами, а для Entry бы давал только то место, которое пустое. Рамка рисуется через стиль (см. gtk_paint_box например), который можно получить у самого этого Entry в момент экспоза, т.е. когда вы оба 100% смаплены.

Стандартные виджеты частенько устроены настолько по-идиотски, что лучше *всегда* вместо наследования использовать композицию — наследоваться по вкусу от Container/Bin/[HV]Box и содержать что-то в себе. Да, неудобно что нет методов и ты «уже не тот». Придется писать прокси, или давать публичный доступ через ->entry или ro-проперть (всякие gtk_bin_get_child и без того будут работать).

Если все это делается вообще только для себя, то можно не заниматься писаниной класса, а использовать EventBox с невидимым окном, перехватить size-allocate и expose-event и всего делов.

Спасибо, я уже разобрался в чём была причина. Делать составной виджет - он будет выглядеть не родным, «кривым», я изначально пробовал сделать такой, составной виджет. Поэтому решил рисовать на GtkEntry, чтобы всё выглядело красиво и нэйтивно. А причина была в том, что в GtkEntry вложено ещё одно GdkWindow для отрисовки текста, и вот на нём и надо было рисовать кнопку, а не на основном. Сейчас виджет уже рисуется нормально, но есть правда одна проблема, как оказалось у GtkWidget нет события типа resize-event, тут я писал об этом: http://www.linux.org.ru/forum/development/6285965?lastmod=1305888282459#comment-6286732 (комментарий) Т.к мне нужно пересчитывать координаты кнопок на элементе(при изменении размера виджета), когда это делать, если нет события ресайза? Только в событии expose-event, т.е это событие пересчитывает положение конопок и отрисовывает их, имхо неправильное решение, но куда деваться, заупскать из expose-event свой resize-event думаю бедет ещё кривее :)

Некрасиво было, потому что надо энтрёвым стилем рисовать, см. gtk_rc_get_style() со товарищи. Плюс иногда в gtk_paint_*() надо сувать не свой виджет, а тот, который симулируешь, т.к. некоторые долбанутые движки вроде clearlooks'а бывает на класс виджета смотрят, а он не тот. Мне приходилось даже синглтон создавать, щас уж не помню чего именно, чтобы «быть похожим» на стандартный контрол. Плюс надо подсмотреть что там родной энтри передает как detail. В общем, если других правоверных путей не найдется, то это точно можно.

Насчет size-allocate в соседней ветке — какая-то мистика, т.к. это неотъемлемая часть цикла request/allocate при ресайзе несущего окна. Сорец смотрел, вроде все ок. Можно попробовать через внешний g_signal_connect[_after], если и так не попадет — это чо-то новенькое :\ Также можно посмотреть на искуственную реакцию на gtk_widget_size_allocate(), плюс перенести принтфы перед inherited и на всякий делать fprintf(stderr, "!\n") вместо g_printf(). Ну и раз в экспос заходит, можно сравнить там class->size_request и my_size_request.

Но вышеописанное в принципе не очень нужно, если многострадальная кнопка не имеет своего GdkWindow, т.к. это нормально вычислять координаты для рисования в экспозе, все родные контролы так и делают. Фрейм, например, нигде не хранит прямоугольник с заголовоком, но всегда вычисляет его от общего allocation'а. Ненормально в экспозе — двигать иксовые окна, т.к. будет заметное мельтешение и артефакты могут остаться при ресайзе; для того и есть size-allocate.

сделай gtkvbox, положи в него еntry (можно без бордюра), поставь боксу margin по левому краю, сделай его app paintable и загаживай как хошь. только с отрисовкой детей надо немного поколдовать

или возьми vala, унаследуйся от gtk.bin и рисуй на здоровье без майндфаков

эвент называется configure а не resize

Не, некрасиво было не поэтому. Первоначально я делал как: брал HBox, на него клал Entry и Button, убирал у Entry бордюр, и всё это дело упаковывал в Frame, если без фрейма, то смотрелось в принципе не плохо(можно сказать нэйтивно), но это в случае если бы этот «компот» использовался скажем как cell_renderer, но у фрейма, если ему ставить стиль скажем GTK_SHADOW_IN(OUT), вверху появляется «область» из-за которой кнопка просто сжимается(она остаётся такойже квадратной, но маленькой, из-за какого-то бордюра вокруг неё), и кнопка выглядит по уродски(сейчас у меня под рукой нет того кода, или уже собранного бинарника, так бы привёл скриншот или листинг, попробуйте, может получится воспроизвести). Сейчас я рисую сразу на Entry, при отрисовке ставлю detail в «button»:

gtk_paint_box(	widget->style, 
						window, 
					GTK_WIDGET_STATE(widget), 
						shadow_type, 
						&event->area, 
						widget, 
						"button", 
						btn->x, 
						btn->y, 
						btn->w, 
						btn->h);

Пробовал и configure, это событие реагирует на движение окна и изменение его разера, но у меня оно почему-то тоже не среагировало, думаю где-то что-то не переопределил, или может нужно было метод какой родительский вызвать... делал просто:

g_signal_connect(G_OBJECT(button_entry), "configure-event", G_CALLBACK(button_entry_configure), NULL)

configure без event

попробовал и просто configure, не работает, но в консоль ругнулась:

(be:12054): GLib-GObject-WARNING **: gsignal.c:2275: signal `configure' is invalid for instance `0x80a9820'

а туплю я

The ::configure-event signal will be emitted when the size, position or stacking of the widget's window has changed.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows

Тогда получается что оно у меня включено, но сыбытие не отрабатывает, ну да ладно :)

Ну чего ты страдаешь?

10 строк на рабочий прототип из HBox'a: http://s39.radikal.ru/i085/1105/ea/13c359a4febb.png

import gtk

class ButtonEntry(gtk.HBox):
    __gsignals__ = {
        "expose-event": "override",
    }

    def __init__(self, entry, *args):
        gtk.HBox.__init__(self, *args)
        self.set_app_paintable(True)

        self.entry = entry
        entry.set_has_frame(False)
        self.pack_start(entry)

    def do_expose_event(self, event):
        self.entry.style.paint_shadow(event.window, gtk.STATE_ACTIVE, gtk.SHADOW_IN, event.area,
            self.entry, 'entry', self.allocation.x, self.allocation.y, self.allocation.width,
            self.allocation.height)

        gtk.HBox.do_expose_event(self, event)


window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect('destroy', gtk.main_quit)
window.set_border_width(5)

e = gtk.Entry()
be = ButtonEntry(e)
be.set_border_width(5)
be.pack_end(gtk.Button('...'))
window.add(be)

window.show_all()

gtk.main()

Дык, такой вариант я пробовал в самом начале, когда только начинал всё это дело. Сейчас написал, как в вашем примере, получилось вот такое: http://www.imagepost.ru/?v=one_more.png

Вот expose, если раскоментить рисование тени, получается ещё страшнее(вокруг контрола всё заливается тенью) :))

static gint 

gtk_button_entry_expose(GtkWidget * widget, GdkEventExpose *event)

{

	/*

	gtk_paint_shadow(widget->style, 
						widget->window, 
						GTK_STATE_ACTIVE, 
						GTK_SHADOW_IN, 
						&event->area, 
						widget, 
						"entry", 
						widget->allocation.x,
						widget->allocation.y,
					widget->allocation.width,
					widget->allocation.height);*/

	GTK_WIDGET_CLASS(parent_class)->expose_event(widget, event);


return FALSE;
}

в init вынес:

static void 
gtk_button_entry_init(GtkButtonEntry * widget)

{
	widget->entry = gtk_entry_new();
	gtk_entry_set_has_frame(widget->entry, FALSE);
	gtk_widget_set_app_paintable(widget, TRUE);
	gtk_box_pack_start(GTK_BOX(widget), widget->entry, TRUE, TRUE, 0);
}

В gtk_paint_shadow() тебе надо передавать инстанцию GtkEntry, точнее сказать «то, для чего G_OBJECT_TYPE() вернет GTK_TYPE_ENTRY». А у тебя widget суется — это не знаю тут уже что, наверное GtkHBox. Я ж говорю *есть* разница при отрисовке, т.к. многие движки тем зачем-то смотрят в имя класса, а не в деталь, как задумано. Может на теме baverman'а оно и было бы одинакое, но код у него правильный.

GtkEntry *NATIVE = self->entry; gtk_paint_shadow(NATIVE->style, widget->window, GTK_STATE_ACTIVE, GTK_SHADOW_IN, &event->area, NATIVE, «entry», widget->allocation.x, widget->allocation.y, widget->allocation.width, widget->allocation.height);

На обычном клирлуксе батон будет отличаться, хотя с первого взгляда можно и не уловить :) Нарисуй побольше, 200х200 в разных стейтах и увидишь. Я в свое время тоже все это поле перекопал, пришел вот к чему:

Есть понятие «внешнего вида контрола», этот код лежит в engine.so, который у каждого на вкус и цвет. Есть понятие «поведение виджета», этот код для всех стандартный. Связь между ними такова: движок при отрисовке смотрит на 1) стиль, т.е. хинты gtkrc, которые класс-зависимые, 2) класс виджета (==G_OBJECT_TYPE(...)), 3) детайл. То есть фактически связи через детайл почти нет, почти всегда есть жесткая привязка к классу.

Исходя из всей этой ситуации я пришел к выводу, что в GTK нет смысла наследоваться, т.к. это толком никаких плюсов не дает. Единственный выбор, который я делаю — это наследоваться от GtkContainer'а со товарищи, или же просто написать функцию, которая c помощью g_signal_connect() и g_object_set_data() сляпает композит внутри GtkEventBox'а, прицепит нужный функционал, и вернет его как будто это мой кастомный виджет.

То, что у вас так выглядит, может это из-за темы?

Нет, как уже отметили, надо прикинуться GtkEntry в paint_shadow.

если изменять размер виджета, то кнопка увеличивается, а поле остаётся с постоянным размером.

Да, издержки HBox. Прототип #2

import gtk

class ButtonEntry(gtk.Container):
    __gsignals__ = {
        "size-request": "override",
        "size-allocate": "override",
        "expose-event": "override",
    }

    def __init__(self, entry, button):
        gtk.Container.__init__(self)
        self.set_has_window(False)
        self.set_redraw_on_allocate(True)
        self.set_app_paintable(True)

        self.entry = entry
        entry.set_has_frame(False)
        self.entry.set_parent(self)

        self.button = button
        self.button.set_parent(self)
        self.border = 3

    def do_size_request(self, req):
        w, h =  self.entry.size_request()
        req.width = w + h + self.border * 2
        req.height = h + self.border * 2

    def do_size_allocate(self, allocation):
        self.allocation = allocation

        x, y, w, h = allocation.x, allocation.y, allocation.width, allocation.height
        hh = h - self.border * 2
        ww = w - self.border * 2

        entry_alloc = gtk.gdk.Rectangle(x + self.border, y + self.border, ww - hh, hh)
        self.entry.size_allocate(entry_alloc)

        button_alloc = gtk.gdk.Rectangle(x + self.border + ww - hh, y + self.border, hh, hh)
        self.button.size_allocate(button_alloc)

    def do_expose_event(self, event):
        self.entry.style.paint_shadow(event.window, gtk.STATE_ACTIVE, gtk.SHADOW_IN, event.area,
            self.entry, 'entry', self.allocation.x, self.allocation.y, self.allocation.width,
            self.allocation.height)

        gtk.Container.do_expose_event(self, event)
        return True

    def do_forall(self, internal, callback, data):
        callback(self.entry, data)
        callback(self.button, data)

window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect('destroy', gtk.main_quit)
window.set_border_width(5)

be = ButtonEntry(gtk.Entry(), gtk.Button('...'))
window.add(be)

window.show_all()

gtk.main()

Что самое интересное, я и GtkEntry «прикидывался», по разному попробовал:

   
   GtkButtonEntry * e = GTK_BUTTON_ENTRY(widget);
   gtk_paint_shadow(widget->style, 
                  widget->window, 
                  GTK_STATE_ACTIVE, 
                  GTK_SHADOW_IN, 
                  &event->area, 
                  e->entry, 
                  "entry", 
                  widget->allocation.x,
                  widget->allocation.y,
               widget->allocation.width,
               widget->allocation.height);

результат аналогичный. Вечером выложу сюда архив с сорсом, и заодно поиграюсь с темой, у меня используется «клирлукс». Потому как странно, код вроде одинаковый, и пробовал по всякому, а «результаты» не очень :)

widget->style попробуй заменить на e->style.

e->entry->style видимо имелось ввиду

e->entry->style видимо имелось ввиду

Да, верно, на сях под Gtk ни разу не писал, недоглядел.

Вот, выкладываю архив с сорсом, всё лишнее из кода выкинул, оставил минимум, что необходимо. GTK_WIDGET(e->entry)->style тоже не помогло, не меняецо оно :(

http://www.fayloobmennik.net/649894

Запустил свой виджет на клеарлуксе тот же результат: paint_shadow заливает всё синим. Надо просто аккуратнее с размером GtkEntry обращаться и всё будет пучком.

Блин, не могу потестить, среды нету, но на первый взгляд разница в аргументе state, см. [1]. Там кстати чуть ниже в случае интериор-фокуса что-то дорисовывается, тоже можно забрать )) Сорцы вообще хорошая вещь )

[1] http://www.koders.com/c/fid656267515125B7486ACE41475551665305D824F6.aspx?s=qu...

Там бинарник в архиве есть и уже готовые make и cmake файлы, если пересобрать захочется :) А сорсы я как раз параллельно читаю(с git.gnome.org), сейчас смотрю, что можно сделать с set_inner_border, чтобы косяков не было.

Т.е на клеарлуксе косячит, а на той(первоначальной) теме всё нормально? Хмм... поэтому я и не стал делать его композитным, думаю отрисую кнопочку сам :)

а на той(первоначальной) теме всё нормально?

Да, на моей текущей теме твой виджет работает нормально.